composer校验分三类：json语法（用php -r json_decode定位）、字段语义（需composer validate --strict --no-check-publish）、vendor文件哈希（用composer_experimental=1 composer verify-checksums --strict），缺一不可。
Composer 文件校验不是“运行一个命令就完事”，它分三类完全不同的检查目标：JSON 语法是否合法、字段语义是否合规、vendor 文件内容是否被篡改。混用命令或跳过前提条件，结果全是假阳性。
php -r json_decode() 是唯一能准确定位 JSON 语法错误的方式
composer validate 对 config.json 和 composer.json 的处理完全不同：composer validate 只读 composer.json，对全局配置 config.json 完全无视；而 config.json 出错时，Composer 会静默降级或报奇怪的网络错误（比如 “Could not find package”），根本不会提示是配置文件坏了。
- 直接执行这行命令，错误位置和原因一目了然：
php -r "$j = file_get_contents('config.json'); $d = json_decode($j); if (!$d) { echo 'JSON error: ' . json_last_error_msg() . "\n"; }" - 常见错误类型：
Unexpected character→ 中文引号、全角冒号、零宽空格（U+200B）；Syntax error→ repositories 数组最后一项多逗号；Malformed UTF-8 characters→ 文件带 BOM 头 - VS Code 打开
config.json后右下角必须显示 “UTF-8”，不是 “UTF-8 with BOM”；粘贴前务必删掉所有//或/* */注释——JSON 不支持注释
composer validate --strict --no-check-publish 是 CI 中唯一可信的语义校验
不加 --strict 的 composer validate 基本没用：它把拼错的 "autoloader":{}、废弃的 "minimum-stability": "dev-master"、缺失的 "description" 全部当警告放过，exit code 还是 0。CI 流水线里等于没校验。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 必须固定使用：
composer validate --strict --no-check-publish -
--no-check-publish关键在于跳过 Packagist 网络请求，避免因 DNS 或防火墙导致流程中断 - 报错信息里写的
line 12 at column 5就是真实出错点，别重读全文——直接跳转编辑器定位那一行附近，盯末尾逗号、单引号、隐藏字符
COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict 是唯一校验 vendor 文件真实哈希的命令
composer install 只校验下载包解压前的 SHA256，而 verify-checksums 才真正打开 vendor/ 目录，逐文件归并字节流再算一次 SHA256，跟 composer.lock 里的 dist.sha256 比对。两者对象和时机完全不同。
- 必须显式启用实验模式：
COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict；不设环境变量或不加--strict，命令根本不存在或永远返回成功 - 它跳过
type: "path"包和没有dist.sha256字段的老私有包，但不会报错——这意味着漏检风险得你手动兜底 - 最危险的是
vendor/autoload.php这类生成文件：它会被扫描，但不在任何哈希记录中；一旦被注入恶意代码，verify-checksums会失败，可它本身无法告诉你哪一行被改了
composer audit 的三个硬性前提缺一不可
composer audit 不是“装了就能扫”，它只比对 composer.lock 中记录的精确版本与 FriendsOfPHP 安全数据库，且依赖三个刚性条件同时满足。
- 先确认版本：
composer --version必须 ≥ 2.5.0；再启用实验特性：composer config --global experimental.audit true；最后验证注册成功：composer list | grep audit -
audit完全不读vendor/目录，也不解析composer.json；如果 CI 中composer install --no-interaction没跑成功，composer.lock就不存在或不完整，audit必报Could not find composer.lock - 输出建议加参数：
--fixed显示最小修复版本，--format=json供jq提取critical条目做门禁，--with-dev避免漏掉测试工具链里的高危漏洞
真正难的不是运行哪个命令，而是理解每个命令的校验边界：JSON 解析器不管字段含义，validate 不管文件内容，verify-checksums 不管代码逻辑，audit 不管私有包。漏掉任一环，线上就可能跑着被篡改过的 autoload.php。
