必须启用Packagist签名验证并配置元数据镜像：运行composer config -g security.signature-verification true，确保composer diagnose显示signature verification: OK和secure-http: OK，禁用repo.packagist直接替换，改用repos.packagist仅代理元数据，包文件仍走官方带签名CDN。
composer install 时怎么确认包没被篡改
靠 composer.lock 的 dist.shasum 不够——它只校验 ZIP 解压后文件哈希，但恶意包可能在解压后、自动加载前就执行 payload。真正能拦住伪造包的，是 Packagist 官方签名机制，前提是 Composer 2.5+ 且配置启用。
必须同时满足三件事：
- 运行 composer config -g security.signature-verification true（低于 2.5 版本会报错 Unknown configuration setting "security.signature-verification"）
- 确保 composer diagnose 输出含 signature verification: OK 和 secure-http: OK
- 不要用 repo.packagist 直接替换源，否则签名字段丢失；应改用 repos.packagist 仅代理元数据请求
现象验证：如果 composer install 拉下包后，vendor/ 中某文件内容与 composer.lock 里 dist.shasum 不一致，但 composer diagnose 显示 signature verification: disabled，说明签名校验根本没生效，镜像配置已绕过安全链路。
为什么换阿里云镜像后反而更不安全
因为 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 是彻底替换源，而国内镜像不提供 signature 字段——这个字段只由 packagist.org 在 HTTPS 响应头中注入。一旦替换，Composer 自动跳过签名验证，静默接受任何 ZIP 包。
正确做法是保留官方源语义：
- 先关掉旧式替换：composer config -g repo.packagist false
- 再启用元数据镜像：composer config -g repos.packagist.type composer，然后 composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/
- 包文件（.zip）仍走 packagist.org 或其带签名的 CDN，签名校验链不断
常见错误：repos.packagist.url 写成 http:// 协议，或用了已停更镜像（如 https://packagist.laravel-china.org），都会导致 fallback 到无校验模式。
PRE_PACKAGE_INSTALL 插件如何实现实时阻断
这是唯一能在包写入 vendor/ 前触发的事件。默认行为完全不拦截，必须自己写 Plugin，并监听 PackageEvents::PRE_PACKAGE_INSTALL。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
插件内需检查三项关键元数据：
- 作者邮箱是否匹配钓鱼模式（如 admin@gmail.com、support@xxx.com 但域名与包名不符）
- autoload.files 是否含可疑路径（如 "./shell.php"、"../config.php"）
- dist.signature 是否为空或无法验签（调用 openssl_verify() 验证）
任一条件命中，立刻抛 RuntimeException。Composer 会中止当前包安装，并退出整个流程——此时 ZIP 还没解压，autoload 没注册，脚本没执行。
注意：composer audit 不触发该事件，它只扫描 composer.lock 里的已知 CVE，对未入库的 0day 或私有包无效；scripts 字段也不可靠，恶意逻辑常藏在测试文件或 base64 字符串里。
allow-plugins 白名单为什么不能设为 true
"allow-plugins": true 等于关闭所有插件闸门，包括你没意识到的 transitive 依赖带来的二级插件。Composer 2.2+ 默认是 {"*": false}，安全起点就是“全拒”，再按需放行。
正确写法是精确声明："config": {"allow-plugins": {"symfony/flex": true, "laravel/pint": true}}
包名必须完全匹配，不支持通配符（如 "*/*" 或 "laravel/*"）
生产部署时，还要加 --no-plugins 参数（位置必须是 composer install --no-plugins，不是 composer --no-plugins install）。如果某插件仍报错，说明它依赖另一个未授权插件，得顺藤摸瓜补全白名单——漏一个，整条链就失效。
签名验证和插件拦截不是“开了就万事大吉”的开关，而是两层不同粒度的防线：前者防传输劫持和镜像污染，后者防作者账户被盗或包内逻辑投毒。最容易被忽略的是元数据镜像和包文件下载路径的分离——它们必须分属不同通道，且签名只绑定后者。一旦混淆，安全模型就塌了半边。
