镜像同步本身不等于安全，因主流公开镜像（阿里云、腾讯云、清华源）均不生成也不透传packagist.org的signature字段，导致composer静默跳过签名验证，无法防范中间人攻击或缓存污染。
为什么镜像同步本身不等于安全
镜像同步只是把 packagist.org 的元数据（如 packages.json）和包文件（.zip）复制到本地或私有服务器，它不生成、不验证、也不透传官方签名字段。所有主流公开镜像（阿里云、腾讯云、清华源）均不转发 signature 字段——这意味着一旦同步过程中上游被污染、中间被劫持，或镜像自身缓存滞后，下游 composer install 就会静默拉取篡改后的包，且不报错。
常见错误现象包括：composer diagnose 显示 secure-http: OK 但缺 signature verification: OK；CI 构建成功，线上却执行了未声明的 post-install-cmd；vendor/ 中文件哈希与 composer.lock 不符却无提示。
同步时必须保留 signature 字段的三种方式
真正能防中间人攻击的同步，核心是让下游 Composer 仍能拿到 packagist.org 原始响应里的 signature。这只有三类可行路径：
- 使用支持签名透传的私有镜像服务（如自建 mirror + 反向代理 + header 透传
X-Composer-Signature） - 放弃“全量镜像”，改用
repos.packagist元数据代理模式：只同步packages.json，包文件仍走官方 CDN，由 Composer 自动校验dist.shasum和signature - 在同步脚本中主动抓取 packagist.org 的原始 HTTPS 响应（需带
Accept: application/json和有效 User-Agent），提取并注入signature字段到本地packages.json，再落地
注意：rsync 或 curl -O 直接拉镜像站文件，无法获得 signature——因为镜像站压根没这个字段。
inotify 同步不能替代 HTTPS + 签名校验
inotifywait 只监听本地文件系统事件，比如 packages.json 被写入完成。它对上游是否已更新、响应是否被篡改、签名是否有效，完全无感知。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
典型误用场景：
- 用
inotifywait -e close_write监听packages.json，但 rsync 实际用--inplace写入，导致捕获的是未 flush 的脏数据 - 监听到了文件变更就立刻触发推送，下游 rsync 拉到半截文件，
composer install解析失败或静默跳过校验 - 没加
sync && touch .ready类原子标记，无法区分“写入中”和“已就绪”
正确做法是：同步脚本末尾执行 sync && touch /path/to/.ready，inotifywait 改为监听 .ready 文件的 IN_CREATE 或 IN_MOVED_TO，再触发下游分发。
如何验证同步结果是否真能防投毒
别信日志，要看 Composer 是否实际触发了签名验证链。验证步骤必须全部满足：
- 运行
composer config -g repo.packagist false（禁用危险的全局源替换） - 确认
composer config -g repos.packagist.url是 HTTPS 地址，且以/结尾（例如https://mirrors.aliyun.com/composer/） - 执行
composer diagnose，输出中必须同时出现secure-http: OK和signature verification: OK - 手动检查任意一个包的
composer.lock条目，确认dist块含非空shasum字段，并运行composer install -v观察是否出现Downloading https://+Extracting archive（说明走 dist 路径，校验生效）
最关键的盲点是：哪怕用了阿里云镜像，只要没关掉旧式 repo.packagist 配置，签名验证就永远不生效——这个开关状态不会自动继承，也不会在 composer diagnose 里明确警告，只能靠人工核对配置项是否存在。
