composer status 仅检测以 git source 方式安装且含未提交变更的包，依赖 .git 目录而非文件内容比对；dist 包、无 source 配置的私有包均被跳过；需通过 --prefer-source 切换模式并重装才能生效。
composer status 不是万能的“文件哈希校验器”，它只对以 Git source 方式安装、且工作区有未提交变更的包有效。其他情况——比如你改了 vendor/ 里的代码但没报 modified，大概率不是命令坏了，而是它根本没检查你改的那个包。
为什么 composer status 没输出，但 vendor 里明明被改了？
这是最常被误解的一点：composer status 的检测机制完全依赖 Git 工作区状态，而非文件内容比对。它只扫描那些带 .git 目录的包（即通过 --prefer-source 安装的），跳过所有 dist 包（zip 解压，无 .git）。
- 运行
composer show monolog/monolog，如果输出里没有source字段，说明这个包当前就是 dist 模式，status对它完全静音 - 私有包若在
composer.json中漏写了"type": "package"或没配"source"，即使你本地有 Git 仓库，Composer 也不会识别 -
prefer-dist是默认行为，90% 以上的 Packagist 包都走 zip 下载，vendor/xxx下压根没.git
怎么让 composer status 真正检测到修改？
核心动作只有一个：把目标包切换成 source 模式。否则 status 就是摆设。
- 重装单个包：
composer update --prefer-source monolog/monolog - 全局强制 source（推荐团队统一）：
composer config prefer-source true，该配置会写入项目composer.json的config块 - 临时生效（CI 场景）：
composer install --prefer-source或composer update --prefer-source
注意：改完后要重新运行 composer status，旧的 dist 包不会自动转 source，必须重装。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
看到 modified 后，怎么快速定位改了啥？
composer status -v 只告诉你“哪个包被改”和“路径”，不显示实际差异。真要看改动，必须进到包目录用 Git 命令。
- 手动流程：
composer status -v→ 找到包名（如symfony/console）→cd vendor/symfony/console→git status -s或git diff --stat - 一行脚本查所有 modified 包的简略状态（Linux/macOS）：
composer status | grep "modified" | cut -d' ' -f1 | xargs -I{} sh -c 'echo "\n=== {} ==="; cd vendor/{} && git status -s 2>/dev/null' - 别依赖
composer status的输出格式做自动化判断——加-v后字段顺序可能变，适合人眼扫，不适合解析
composer status 空输出就代表 vendor 干净吗？
不。空输出只代表「所有 source 安装的包都没被改」，不代表整个 vendor/ 是干净的。
- dist 包哪怕你删了
vendor/xxx/src/整个目录，status也沉默 - source 包如果你执行过
git checkout .或git clean -fd，它也会安静 - CI/部署前真正可靠的“一致性检查”是：
composer install --no-dev --dry-run+ 校验composer.lock是否被篡改
真正难的不是敲命令，而是理解 composer status 背后绑定的是 Git 工作区快照，不是 lock 文件哈希，也不是文件内容指纹。
