composer.lock 文件需设系统级只读权限（linux/macos用chmod 444，windows用attrib +r）才能真正防止被意外重写，因composer默认允许写入且--no-scripts等参数无效。
composer.lock 文件被意外重写，根本不是 Composer “没锁住”，而是它默认允许写入——只要权限放开、命令用错、或流程失控，它就敢改。唯一真正起效的“只读”，是让操作系统拒绝写入。
怎么给 composer.lock 加系统级只读锁
Linux/macOS 下直接执行：chmod 444 composer.lock。这会让文件对所有用户（owner/group/others）只有读权限，Composer 在尝试写入时会立刻报错：file_put_contents(./composer.lock): failed to open stream: Permission denied。
- 别用
555（可执行权限），Composer 不需要执行权，某些 CI 环境反而会因权限异常中断 - Windows 用户可用：
attrib +R composer.lock - CI 脚本里加这句更稳妥：
chmod 444 composer.lock || true（|| true防止文件不存在时报错退出） - 这个操作不改任何配置、不依赖插件，纯靠文件系统拦截，最硬核也最可靠
为什么 --no-scripts 或 --no-plugins 压根不防 lock 被改
这两个参数只控制是否执行脚本和插件，跟 composer.lock 的读写毫无关系。决定 lock 是否被修改的，只有两个事实：
- 你运行的是
composer install还是composer update—— 前者默认不改 lock，后者一定重写 -
composer.json和现有composer.lock是否一致 —— 若不一致，install会警告但不自动重写；但若 lock 缺失、损坏或用了--ignore-platform-reqs等参数，行为可能退化为 update
靠参数“预防修改”是错觉，系统级只读才是第一道防线。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
CI/CD 中必须加的两道校验
光设只读还不够，CI 流水线得主动盯住 lock 文件状态：
- 构建开始前检查是否被改动：
git diff --quiet composer.lock || (echo "composer.lock changed! Commit it first."; exit 1) - 部署时强制走锁定安装：
composer install --locked --no-interaction --prefer-dist——--locked会让 Composer 直接失败，而不是悄悄生成新 lock - 别信
composer config --no-updates，它不生效；也别在 CI 里跑composer update，哪怕只指定一个包，lock 文件照样被重写
手动改 composer.lock 是最危险的“捷径”
它不是配置文件，而是包含包版本、哈希值、依赖树结构、content-hash 的完整快照。改错一个逗号、漏掉一个子依赖、哈希没同步更新，就会导致：
-
composer install报Invalid argument supplied for foreach()（实际是 JSON 解析失败） - 本地能跑，CI 构建失败，因为校验逻辑更严格
- 别人
git pull后install，装出完全不同的vendor目录
真要重写 lock，请用 composer update --lock —— 它不碰 vendor，不查远程，只按当前已安装状态安全重建快照。其他任何方式，都是在赌运气。
