不该在 postcreatecommand 或 oncreatecommand 中直接写 composer install；应改用 initializecommand 或 postattachcommand 在工作区挂载后执行，或在 dockerfile/features 中预装依赖。
devcontainer.json 里该不该写 composer install？
不该直接写 composer install 在 postCreateCommand 或 onCreateCommand 里——Codespaces 启动时容器尚未挂载工作区，vendor/ 写入会失败或被丢弃。
正确做法是利用 dev container 的「构建时安装」能力，在 Dockerfile 中预装依赖，或用 features 声明式安装 PHP + Composer，再在 initializeCommand（推荐）或 postAttachCommand 中运行 composer install ——此时工作区已挂载，路径可写。
-
initializeCommand在容器启动且 VS Code 客户端连接后执行，适合做项目级初始化 - 避免用
postCreateCommand：它在构建完成但工作区未挂载时触发，composer install会报Could not open input file: composer.phar或写入空目录 - 若项目有
composer.lock，优先用--no-dev（CI 场景）或保留--dev（本地开发需测试工具）
用 Features 还是自定义 Dockerfile？
90% 的 PHP 项目用 GitHub 官方 ghcr.io/devcontainers/features/php + composer Feature 更稳。Features 自动处理 PHP 版本、扩展、PATH 和全局 composer 可执行文件位置，省去手动 curl -sS https://getcomposer.org/installer | php 的路径和权限问题。
自定义 Dockerfile 仅在需特殊扩展（如 grpc）、非标 PHP 构建参数或离线环境时必要。
- Features 支持版本锁：
"ghcr.io/devcontainers/features/php": { "version": "8.2", "extensions": ["xdebug"] } - Composer Feature 默认安装到
/usr/local/bin/composer，无需额外chmod +x - Features 的安装日志在 Codespaces 启动面板可见，出错比手写 Dockerfile 更易定位
composer install 报错 “Your requirements could not be resolved” 怎么办？
Codespaces 默认使用 Ubuntu 镜像，PHP 环境干净但缺少某些扩展（如 mbstring、xml），导致 composer install 在解析依赖时静默失败，或报错提示不明确。
不是 Composer 本身的问题，而是底层扩展缺失引发的依赖约束冲突。
- 检查
php -m输出是否包含mbstring、xml、json、ctype——缺哪个补哪个 - 在 Features 配置中显式声明所需扩展：
"extensions": ["mbstring", "xml", "json", "ctype"] - 若用自定义 Dockerfile，确保在
apt-get install后调用docker-php-ext-install，而非只装 deb 包 - 临时验证：在 Codespaces 终端运行
php -r "echo extension_loaded('mbstring') ? 'ok' : 'fail';"
vendor 目录要不要加进 .gitignore？
要。但 Codespaces 里常有人误把 vendor/ 提交进 Git，因为本地没配好，又在 Codespaces 里重新 composer install 生成了它。
一旦提交，后续所有协作者拉代码都会带上这个平台相关、体积大、易冲突的目录，反而破坏环境一致性。
-
vendor/必须出现在项目根目录的.gitignore中（一行即可） - Codespaces 启动后首次运行
composer install生成的vendor/是临时的，关机后不保留 —— 所以每次重开都得重装，这反而是设计预期 - 如果想跳过重复安装，可在
devcontainer.json中加"cache": true（仅限部分 Features 支持），但不如靠composer.lock和 CI 缓存可靠
最易被忽略的是：Codespaces 的文件系统在容器重启后不保留 vendor/，但用户常以为它像本地一样“一直存在”。结果改了 composer.json 却忘了 composer update，或者误以为 vendor/ 被缓存了而跳过安装步骤 —— 实际上每次新环境都是裸装，composer.lock 是否存在、是否更新，直接决定依赖能否复现。
