composer outdated 无法发现补丁需求，因为它只比对 composer.json 版本约束与 packagist 最新版本，完全忽略 vendor/ 中手动打的补丁；即使源码被修改，只要版本号和 composer.lock 未更新，仍显示“up to date”。
composer outdated 为什么不能直接发现补丁需求
因为 composer outdated 只对比 composer.json 中声明的版本约束与 Packagist 上的最新可用版本，它完全不感知你是否在 vendor/ 里手动打了补丁（比如用 git apply 或 patch 修改过源码）。哪怕某个包已被你改得面目全非，只要版本号没变、composer.lock 没更新，它就显示“up to date”。
真正要识别补丁残留，得换思路：看修改痕迹，而不是看版本号。
检查 vendor 包是否被手动修改的三个实操方法
以下命令均需在项目根目录执行，且假设你使用 Git 管理项目（绝大多数情况如此）：
- 运行
git status --porcelain vendor/—— 这是最直接的方式。只要输出非空（比如出现MM vendor/symfony/console/Command.php），说明该文件已被修改且未提交（即补丁未纳入版本控制） - 对单个包深度检查：进入
vendor/package-name，执行git diff --quiet && echo "clean" || echo "modified"。注意：这仅在包本身是 Git 克隆（而非 zip 下载）时有效；Composer 默认对 dist 包跳过 Git 克隆，所以先确认该包是否含.git目录 - 用
composer show package/name --installed查看安装方式：source表示 Git 克隆（可 diff），dist表示 zip 解压（手动 patch 后 git 无法追踪，只能靠文件哈希比对）
补丁是否“需要保留”的关键判断点
不是所有修改都值得继续维护。重点看：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 补丁是否解决当前稳定版仍未修复的 bug？查对应包的 GitHub Issues 和最近 release note，确认
main或最新 tag 是否已合入你的修改 - 补丁是否绕过设计限制（比如强行 public 某个 private 方法）？这类 hack 很可能在下次大版本升级中彻底失效
- 是否已有官方替代方案？例如用
composer config extra.symfony.allow-contrib true启用社区 bundle，就不用 patch 核心包来加功能 - 补丁是否只影响 dev 环境？比如仅用于本地调试的日志注入，上线前应自动剥离，不应进
vendor/
自动化检测补丁残留的小脚本建议
把下面这段保存为 check-patches.sh，配合 CI 使用：
#!/bin/bash
for dir in vendor/*/; do
[ -d "$dir/.git" ] && (cd "$dir" && git diff --quiet 2>/dev/null) || {
echo "⚠️ $dir likely patched or installed as dist"
}
done
注意：它不会告诉你改了什么，但能快速圈出可疑目录。后续人工进目录跑 git diff 或 diff -r（对 dist 包）才能定位具体变更。
真正的难点不在检测，而在于每次 composer update 后，你要决定是丢弃补丁、重适配、还是推动上游合并——这些没法靠命令自动完成。
