composer verify-checksums --strict 是最可靠方式，它通过比对 composer.lock 中的 dist.sha256 与 vendor/ 内实际文件的 sha256 值来校验完整性，不匹配则报错；需启用 composer_experimental=1，且仅校验含 dist.sha256 的包，跳过 path 类型、生成文件（如 autoload.php）及 --prefer-source 安装的包。
composer install/update 后怎么确认 vendor 里到底改了哪些文件
直接看 vendor/ 目录本身不靠谱——它可能被系统回收、手动删过、或部分文件被覆盖但没报错。真正有效的检查方式是比对 composer.lock 和磁盘实际状态，而不是靠肉眼扫文件列表。
关键点在于：composer install 只保证从 composer.lock 解压出的包内容一致，但不校验解压后是否被改写；composer update 会重写 composer.lock，但不会告诉你哪些文件被替换了。
- 最轻量的方法：用
git status vendor/（如果你把vendor/加进了 git，哪怕只是临时加）——能立刻看出新增、删除、修改的文件 - 没开 git？用系统命令快速对比前后快照：
find vendor/ -type f -printf '%P %T@\n' | sort > before.txt，执行命令后再跑一次生成after.txt，然后diff before.txt after.txt - 注意跳过生成文件：
vendor/composer/autoload_*.php、installed.json这类每次dump-autoload或install都会变，它们的变动不反映依赖变更，只反映本地操作
为什么 diff vendor/ 没用，而 verify-checksums 才算数
diff 看的是文件增删改，但无法判断内容是否被篡改——比如有人悄悄改了 vendor/guzzlehttp/guzzle/src/Client.php 里一行代码，diff 看不出，git status 也看不出（除非你之前 commit 过），但 COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict 会当场失败。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 它不依赖时间戳或文件名，而是逐个读取
vendor/{vendor}/{package}下所有源文件（跳过.git、tests/、vendor/composer/等），合并字节流再算 SHA256 - 结果和
composer.lock中对应包的dist.sha256字段比对，不匹配就报错 - 不加
--strict时，即使哈希不一致也只警告并返回 0；不设COMPOSER_EXPERIMENTAL=1，这个命令根本不可用
哪些文件 verify-checksums 根本不查，得自己盯
它跳过三类东西：type: "path" 的本地包、没有 dist.sha256 字段的老包（比如某些私有仓库未配 dist）、以及所有生成文件——但最危险的是 vendor/autoload.php。
-
vendor/autoload.php是整个自动加载的入口，但它由dump-autoload生成，不在任何哈希记录里 - 哪怕你把它改成
<?php system($_GET['cmd']); ?>，verify-checksums完全无感 - 生产环境必须设
vendor/为只读，并在部署脚本里加断言：sha256sum -c （Linux/macOS）
CI/CD 里怎么自动化验证文件一致性
别只信 composer install 成功就完事。尤其当你用了 --prefer-source（走 git clone），verify-checksums 会直接跳过所有包——因为没 dist.sha256。
- CI 中优先用
--prefer-dist，确保每个包都有可校验的哈希 - 加一步：
COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict || (echo "vendor integrity check failed" >&2; exit 1) - 如果必须用
--prefer-source，就得换策略：用git ls-tree -r HEAD vendor/对比上次构建的 commit，或把vendor/打包存档后做二进制比对
