composer.lock是vendor膨胀的“判决书”，它固化所有依赖（含dev传递依赖），即使加--no-dev也无法清除已记录的dev包；需通过composer update --lock重写lock文件并配合--no-dev安装才能真正精简。
composer.lock 文件本身不直接导致磁盘体积膨胀，但它是 vendor 膨胀的“判决书”——它记录了所有被拉下来的包（含 dev 传递依赖），一旦写入，后续 composer install 就会忠实地还原整个树，哪怕你加了 --no-dev。
为什么 composer.lock 会悄悄变大
lock 文件体积增长，往往不是因为字段变多，而是因为它默默记下了本不该存在的内容：
-
packages-dev数组里还存着"phpunit/phpunit"、"roave/security-advisories"等包的完整 dist/source 描述 —— 即使你本地删了require-dev，只要没重生成 lock，它们就还在 - 某个 dev 包（如
laravel/pint）被另一个 dev 包（如spatie/laravel-ray）间接 require，composer remove只删顶层，lock 里仍保留其全部传递依赖条目 - 执行过
composer update（默认带 dev）后，即使紧接着跑composer install --no-dev，lock 已经固化了 dev 包信息，install 阶段只是“跳过安装”，不是“清除记录”
如何确认 lock 文件是否干净
别只看命令有没有加 --no-dev，直接查文件内容：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
grep -A 5 '"name": "phpunit/phpunit"' composer.lock检查是否出现在"packages"或"packages-dev"里；真正干净的生产 lock 应该只在"packages-dev"有残留（且最好为空） - 运行
composer show --dev，输出为空才说明当前 lock + vendor 是一致的；若有结果，说明 lock 还带着 dev 包元数据 - 检查
"platform"和"platform-check"字段：如果它们包含"php": "8.3"但你线上是 8.1，Composer 可能因平台不匹配而 fallback 到旧版包，间接引入更多依赖
lock 变大后怎么安全瘦身
不能直接删 lock 里的字段，必须走 Composer 的语义流程：
- 先清空
require-dev区块，删掉所有非生产必需的包（比如phpunit、phpstan、laravel/pint） - 运行
composer update --lock（不是composer update），它只重写 lock，不碰 vendor，也不会拉新包 - 再执行
composer install --no-dev --optimize-autoloader，此时 lock 已无 dev 记录，install 才真正轻量 - 若发现某包仍被装进来（比如
sebastian/exporter），说明它同时被生产包和 dev 包 require —— 这是合理共存，不用强删，重点盯住纯 dev-only 包
lock 文件不是日志，是契约。它变大，通常意味着你在某个环节松动了约束边界：一次没加 --no-dev 的 update，一个没清理的 require-dev，或一个被忽略的环境变量覆盖。最危险的是以为“删了 composer.json 里的 dev 就万事大吉”，却忘了 lock 才是部署时的唯一真相。
