composer require --no-update 会修改 composer.json，但仅当指定包名合法且未被声明时；旧版 Composer 或包已存在会导致不写入。
为什么 composer require --no-update 不会改 composer.json？
它其实会改——但只在满足特定条件时。默认情况下，composer require 会先修改 composer.json，再执行 update。加了 --no-update 只是跳过安装依赖这步，composer.json 仍会被写入新包（含版本约束）。如果你发现没改，大概率是因为：
- 你运行的是旧版 Composer（composer.json
- 目标包已存在于
composer.json中（即使版本不同），Composer 默认不覆盖已有条目 - 你用了
--dev但当前包已在require区，或反之，Composer 拒绝跨区移动
如何确保只改 JSON、完全不动 vendor 和锁文件？
用 --no-update 是对的，但得配合明确的范围和约束写法：
- 显式指定版本：比如
composer require monolog/monolog:^2.8 --no-update，避免 Composer 自动解析出意外版本 - 强制写入指定区块：加
--dev或--no-dev明确归属，防止因已有同名包导致静默失败 - 确认当前无未提交的
composer.json修改，否则 Composer 可能拒绝操作（尤其启用了lock严格模式） - 运行后检查
composer.json是否新增了对应条目，以及composer.lock时间戳是否未变
--no-update 后什么时候必须手动 composer update？
不是“必须”，而是“只有这时才真正生效”：
- 新包不会出现在
vendor/目录，autoload也不识别它，直接use会报Class not found - 如果后续运行
composer install，它会按旧composer.lock还原，新添加的包会被忽略——因为 lock 文件里没有记录 - 所以，想让改动落地，最终仍需运行
composer update monolog/monolog（只更新单个）或composer update（全量），才会生成新 lock 并装进 vendor
替代方案：手动编辑 composer.json 更安全？
在 CI/CD 或批量脚本中，手动改 JSON 确实更可控，但要注意：
- JSON 格式必须合法，缩进不影响，但逗号遗漏、引号不闭合会导致
composer install直接失败并报错JSON decode error - 版本字段要符合 Composer 版本约束语法，比如
"^2.8"不能写成"2.8.*"（后者虽可解析，但语义不同） - 改完后若不确定，可用
composer validate快速校验结构和字段合法性 - 它绕过了 Composer 的依赖兼容性检查，如果新增包与已有包存在冲突，要等
update时才暴露
--no-update 最常用于“先占位再审核”的场景——比如 PR 中预埋依赖，等代码审查通过后再统一 update。但别忘了，它只是延迟执行，不是取消执行。 
