alpine容器npm install失败主因是musl libc与glibc二进制不兼容，需先确认系统（cat /etc/os-release）、检查报错关键词，再选用musl兼容包、换deb基础镜像或调整devcontainer配置。
Alpine容器里npm install失败，先确认glibc兼容性
Alpine Linux用musl libc，不是glibc——很多Node.js原生模块（比如fsevents、sqlite3）默认只提供glibc编译版本，直接npm install会报Cannot find module或ELF file ABI version invalid。这不是你漏装包，是二进制不兼容。
- 检查报错里是否含
musl、glibc、ELF关键词 - 运行
cat /etc/os-release确认确实是Alpine（而非Ubuntu/Debian镜像） - 优先改用支持musl的包：比如用
sqlite3换成@vscode/sqlite3，它内置musl预编译版 - 实在绕不开glibc依赖？换基础镜像：
node:18-slim（deb-based）比node:18-alpine更稳妥
devcontainer.json里没配好workspaceFolder导致node_modules挂载失败
VSCode Remote-Containers默认把本地node_modules绑定进容器，但Alpine里路径权限或用户ID不一致时，require()会静默失败——控制台没报错，但插件功能不生效。
-
workspaceFolder必须设为/workspace（不能是/或/home），否则挂载后权限被拒绝 - 在
devcontainer.json里显式声明"remoteUser": "node"，避免root用户写入node_modules后普通用户读不了 - 加一条
"postCreateCommand": "npm ci --no-audit"，强制重装并跳过安全扫描（Alpine上npm audit常卡住） - 别用
image字段拉官方node:alpine——它没装python3和make，编译原生模块必崩；改用build字段自定义Dockerfile
调试时找不到@types或ESM模块，其实是tsconfig.json没适配Alpine
Alpine里Node.js默认用CommonJS，但你的tsconfig.json若设了"module": "ES2022"，tsc生成的JS文件会被当成ESM，而VSCode调试器仍按CommonJS加载，结果require('./dist/index.js')直接抛ERR_REQUIRE_ESM。
- 确保
tsconfig.json里"moduleResolution"设为"node"（不是"nodenext"） -
"outDir"路径别带空格或中文，Alpine对路径解析更敏感 - 在
devcontainer.json的customizations.vscode.settings里加"typescript.preferences.includePackageJsonAutoImports": "auto"，避免类型定义丢失 - 验证方式：进容器跑
node -e "console.log(require('./dist/index.js'))"，能执行说明模块加载通了
CI流水线里插件自动更新超时，得关掉Alpine容器里的网络请求
Alpine镜像默认没开DNS缓存，插件初始化时调updateURL查新版本，5秒内连不上就卡死——本地开发可能碰巧成功，CI里必然失败。
- 在
.devcontainer/Dockerfile末尾加：RUN echo '{ "extensions.autoUpdate": false }' > /root/.vscode-server/data/Machine/settings.json - 别信
code --disable-extensions，Remote-Containers里这参数不生效；必须写进VS Code Server的配置文件 - 如果插件硬依赖某API（比如Dify插件要连
http://localhost:5001），在devcontainer.json里用"forwardPorts"显式暴露端口，Alpine的iptables规则比Ubuntu更严格
docker exec -it <container> sh</container>进去，用ls -l node_modules和node -p "process.versions"看真实状态，比猜更快。
