Docker中OpenClaw飞书插件加载失败的根因是模块路径在容器内“迷路”，即插件入口文件中import/require的路径指向容器中不存在的目录（如../../src/plugin-sdk/feishu.js），而非依赖未安装。
客户端加载插件失败，在 docker 环境中通常不是“客户端”本身的问题，而是插件运行时所依赖的上下文、路径或通信链路出了偏差。尤其在 openclaw 这类插件化服务中，所谓“客户端”其实是宿主应用（如 node.js 或 python 进程）在容器内启动后，尝试动态加载飞书等插件模块——这个过程不经过 docker 客户端（docker 命令），但严重依赖容器内的运行环境是否与开发预期一致。
确认插件加载发生在容器内部，而非宿主机
很多人误以为 docker run 启动后，插件就“自动可用”，其实不然。OpenClaw 的插件加载由其主进程主动触发：它会读取配置（如 plugins_dir）、扫描目录、执行 require() 或 import。如果配置路径写的是宿主机路径（比如 /Users/xxx/openclaw/plugins/feishu），而容器里根本没有这个位置，就会报 Cannot find module。
- 检查 OpenClaw 配置中插件目录是否为容器内有效路径，例如
/app/plugins，而非开发机绝对路径 - 确认 Dockerfile 中已将插件代码正确 COPY 或挂载到该路径，且权限可读
- 进入容器验证：
docker exec -it <container> ls -l /app/plugins/feishu
修复模块解析路径：工作目录 + require.resolve 行为
Node.js 插件（如飞书 SDK）常通过 require('@larksuiteoapi/node-sdk') 加载第三方包。这个路径解析依赖两点：当前工作目录（process.cwd()）和 node_modules 位置。若容器启动时工作目录不对，或 node_modules 没装在插件目录下，就会找不到模块。
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 在 Dockerfile 中显式设置工作目录：
WORKDIR /app，并确保npm install在此路径下执行 - 避免在插件子目录里单独
npm install；推荐统一在项目根目录安装所有依赖 - 必要时，在插件入口文件中加一行调试：
console.log('cwd:', process.cwd(), 'paths:', module.paths)
检查 Docker 构建上下文与挂载方式是否隔离了依赖
用 docker run -v $(pwd)/plugins:/app/plugins 挂载插件目录很常见，但容易忽略：挂载会完全覆盖容器内原有目录，包括可能存在的 node_modules 或配置文件。如果插件本身带 package.json 并期望本地安装依赖，挂载后这些文件就“消失”了。
- 优先使用 COPY 复制插件（构建时确定），而非 runtime 挂载，保证环境一致性
- 若必须挂载，确保宿主机对应目录已执行
npm install，且node_modules一同挂载（或使用绑定挂载子目录） - 验证挂载后模块可访问：
docker exec -it <container> node -e "require('/app/plugins/feishu')"
排除 Docker 守护进程干扰——这里其实不相关
注意：插件加载失败和 Docker 守护进程（dockerd）是否运行无直接关系。除非你用到了 dockerode 这类在插件里调用 Docker API 的场景，否则“客户端连不上守护进程”的报错（如 connect ECONNREFUSED /var/run/docker.sock）属于另一类问题，和模块加载失败无关。
- 如果日志里同时出现两种错误，大概率是两个独立问题：一个是插件路径/依赖缺失，另一个是插件代码试图操作宿主机 Docker 但没给权限或没挂载 socket
- 需要操作 Docker 的插件，才需加
-v /var/run/docker.sock:/var/run/docker.sock和对应用户权限
