verify-checksums --strict 是唯一能校验 vendor 目录真实文件完整性的命令，需启用 composer_experimental=1 且必须加 --strict；它逐包扫描 vendor 目录（排除 .git、tests/ 等），归并文件字节流计算 sha256 并与 composer.lock 中 dist.sha256 比对，跳过 type: "path" 包及无该字段的包，不校验 autoload_*.php 等生成文件。
composer install 时自动校验 dist 包哈希，但只在校验下载包解压前
Composer 在 install 或 update 过程中，对通过 dist 方式（zip/tar）安装的包，会自动比对下载文件的 SHA256 哈希与 composer.lock 中记录的 dist.sha256 字段。这个校验发生在解压前——即 zip/tar 文件刚下载完、还没写入磁盘或解压时。
这意味着：
- 校验对象是临时下载的压缩包，不是最终落地在
vendor/里的源文件 - 一旦解压完成，Composer 就不再回看这些文件是否被后续篡改
- 如果本地缓存已存在一个哈希不匹配的坏包（比如镜像源替换过 dist 但没同步哈希），
install可能直接命中缓存、跳过下载和校验，导致“成功安装”却实际引入了被污染的代码
启用 HTTPS 和 secure-http 是防止中间人篡改的第一道防线
HTTP 下载本身不加密，攻击者可能在传输途中替换 dist 包。Composer 默认强制启用 HTTPS，但若你手动配置了非 HTTPS 的私有源或镜像，必须显式开启安全验证：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在
composer.json中设置"secure-http": true（全局默认已是 true，但私有源可能绕过） - 私有仓库 URL 必须用
https://，且 SSL 证书需有效；若使用自签名证书，需在options.ssl中明确设"verify_peer": true和"allow_self_signed": false - 禁用
http://源：运行composer config -g secure-http true可全局拦截不安全源
verify-checksums --strict 才是唯一能验证 vendor 目录真实文件完整性的命令
要确认 vendor/ 里每个包的源文件是否和 composer.lock 完全一致，必须用实验性命令：
- 必须前置环境变量：
COMPOSER_EXPERIMENTAL=1，否则该命令不可见 - 必须加
--strict，否则即使发现哈希不匹配也只警告、返回码仍是 0（CI 会误判为成功） - 它递归读取
vendor/{vendor}/{package}/下所有非排除路径的文件（跳过.git、tests/等），合并字节流后计算 SHA256，并与composer.lock中对应包的dist.sha256比对 - 不校验
vendor/composer/autoload_*.php等生成文件，但会扫描并失败于被手动改过的vendor/autoload.php（它无哈希记录）
最危险的盲区：autoload.php 和 path 类型包完全游离在校验体系外
verify-checksums --strict 不报错，不代表 vendor 安全。两个关键漏洞点常被忽略：
-
vendor/autoload.php是整个项目的入口引导文件，但它由 Composer 动态生成，不参与任何哈希校验。被注入恶意代码时，verify-checksums完全无法感知 -
type: "path"的本地包（如开发中的私有库）不带dist.sha256，verify-checksums直接跳过，不警告也不校验 - CI 中用了
--prefer-source？那所有 git clone 的包都无dist.sha256，校验形同虚设
生产部署前务必：chmod -R 555 vendor/ 设为只读，并单独用 sha256sum vendor/autoload.php 断言其内容未变。
