composer validate 默认只做基础 json 和字段存在性检查，不拦截逻辑错误；防 ci 翻车必须组合使用 --strict（校验字段合法性、拼写、弃用项）和 --dry-run（验证依赖可达性与兼容性），--lock 则强制校验 composer.json 与 composer.lock 的哈希一致性。
composer validate 默认只做基础语法和字段存在性检查，不拦逻辑错误；真要防 CI 翻车，必须加 --strict 和 --dry-run 两步走。
composer validate 报错但没给行号，怎么快速定位问题？
错误信息里写的 line 23 at column 17 就是真实出错位置，别从头重读。常见元凶有：
- 末尾多逗号（尤其在对象最后一项后）
- 粘贴进来的中文标点，比如全角
，或： - 用了单引号代替双引号，如
'require': {...} - 残留的
// 注释或/* */（JSON 不支持） - 文件编码是
UTF-8 with BOM（Windows 记事本易中招），右下角确认是纯UTF-8
更快的办法：用 php -l composer.json 过一遍，PHP 自带解析器报错更准；或粘贴到 JSONLint 高亮看。
为什么 validate 通过了，install 却报包不存在或版本冲突？
composer validate 完全不联网、不查 Packagist、不解析版本约束语义——它只认字符串写得对不对。所以这些都合法：
-
"monolog/monolog": "999.0.0"（validate 通过，install 才发现包不存在） -
"php": ">=8.0"（validate 通过，但当前 PHP 是 7.4，install 直接失败） -
"require": {"acme/utils": "dev-main"}（validate 通过，但远程没main分支，install 卡住）
真正暴露依赖问题的是：composer install --dry-run。它会完整走依赖求解流程：校验包名、解析版本约束、比对 config.platform、检查锁文件一致性，但不下载任何东西。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
CI 流水线里该跑哪些命令才靠谱？
只跑 composer validate 是自欺欺人。推荐组合：
-
composer validate --strict --no-check-publish：拦拼写错误、非法字段、name 格式错（如含空格）、autoload 路径类型错（数组 vs 字符串） -
composer install --no-interaction --no-progress --dry-run：验证依赖可解性，且不污染 vendor 缓存 -
composer dump-autoload --no-interaction --dry-run：确认 autoload 路径真实存在、PSR 规则没写反
注意：--dry-run 在 Composer 2.5+ 才稳定支持；旧版 CI 应锁定 Composer 版本（如 2.7.7），避免行为差异。
composer validate --lock 是干啥的？什么时候必须加？
composer validate --lock 不是“顺便看看”，而是强制比对 composer.json 的 hash 和 composer.lock 中记录的 hash 是否一致。如果你手动改过 composer.json 却忘了 composer update，这步就会失败。
它和 --strict 可共存，但意义不同：--strict 拦配置写法错，--lock 拦配置与锁文件脱节。团队协作中，这个检查能防止“本地能跑，CI 报错”的经典甩锅场景。
