如何在Composer中通过脚本重写配置文件

Composer脚本执行时应使用PHP原生JSON操作安全修改配置：先json_decode读取并容错解析，修改数组后用json_encode（带JSON_UNESCAPED_UNICODE和JSON_PRETTY_PRINT）写入，写入前备份原文件，写入后用json_last_error校验，失败则自动还原；禁用sed等文本替换，因其无法可靠处理跨行、特殊字符及格式变化。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

Composer脚本执行时如何安全修改配置文件

这里有个常见的误区：很多人把Composer的scripts当成一个普通的shell脚本沙盒来用。其实不然，它的执行环境——包括工作目录、环境变量、用户权限——都直接受制于当前运行Composer的方式（是全局安装还是本地执行）。在这种环境下，如果图省事，直接用sed或者一句php -r去硬写配置文件，风险可不小。轻则覆盖掉关键内容，重则直接破坏JSON格式，万一配置文件里还带了注释或者非标准结构，那场面就更难收拾了。

所以，一个更稳妥的实操建议是：优先使用PHP原生的JSON操作函数，彻底告别文本替换的思维。具体可以这么做：

• 读取时，用json_decode(file_get_contents($file), true)，它能更好地处理一些“不完美”的JSON，比如末尾多余的逗号或者空格。
• 修改完数组数据后，输出用json_encode($data, JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT)。这组参数很关键，能保证中文正常显示，并且输出格式美观易读。
• 动笔之前先备份，这是铁律：file_put_contents($file . '.bak', $original_content)。
• 写入之后也别急着收工，用json_last_error()校验一下结果是否合法。一旦发现错误，立刻触发自动还原，把备份文件恢复回去。

在 composer.json 中定义可复用的重写脚本

别再把复杂的逻辑硬塞进一行php -r命令里了，那样既难调试，也容易出错。更专业的做法是，把配置重写的逻辑拆解出来，写成独立的PHP脚本文件，然后在composer.json里注册成命令。这样做，后续调试、写单元测试、甚至传递参数都会方便得多。

举个例子，你可以在项目根目录下创建一个bin/update-config.php：

#!/usr/bin/env php

写好了脚本，接下来就是在composer.json的scripts节点里把它注册上，比如绑定到安装或更新之后自动执行：
"scripts": {
  "post-install-cmd": [
    "php bin/update-config.php"
  ],
  "post-update-cmd": [
    "php bin/update-config.php"
  ]
}

为什么不能用 shell 脚本直接 sed 替换 version 字段
你可能会想，不就是改个版本号吗，用sed一句命令不就搞定了？比如sed -i 's/"version":.*$/"version": "1.2.3",/' config.json。但实际情况是，这种做法极不可靠，可以说是埋下了无数个坑：

跨行问题：当JSON文件使用了JSON_PRETTY_PRINT美化格式后，一个键值对很可能分散在多行，sed的单行处理模式直接就失效了。
结构不确定性：JSON字段的顺序是不固定的。version字段可能在文件末尾，后面没有逗号；也可能在文件中间，后面必须跟逗号。一条简单的正则根本无法应对所有情况。
特殊字符灾难：如果值里面包含了引号、斜杠、反斜杠，sed的正则表达式很容易崩溃，或者导致错误的替换。
环境差异：Windows下的sed和GNU sed行为常常不一致，在持续集成（CI）环境中很容易因此出错。

说到底，真正稳定的方法只有一条：走完整的JSON解析链——读取、修改、校验、写入。哪怕为此多写几行PHP代码，也远比花半天时间去调试一个脆弱的sed正则表达式要划算得多。

注意 post-root-package-install 钩子的执行时机
这是另一个容易踩坑的地方。post-root-package-install这个钩子，顾名思义，它只在执行composer create-project时触发一次。更要命的是，它触发的时间点非常早——早到vendor/目录还没生成，Composer的自动加载机制也尚未就绪。
这意味着什么？如果你的脚本里试图require任何第三方包（比如想用symfony/filesystem来操作文件，或者用spatie/json-api来解析JSON），都会直接导致一个致命的错误（fatal error），因为根本找不到这些类。
那么可行的方案有哪些呢？基本上就两条路：

纯原生PHP实现：就像上面例子展示的那样，只使用PHP内置函数，不引入任何外部依赖。这是最安全、兼容性最好的方式。
更换钩子：改用post-create-project-cmd。这个钩子会在vendor/目录初始化完成、自动加载设置好之后才执行，此时就可以安全地引入和使用你需要的第三方类库了。

很多人被卡在这里，就是因为看到钩子名里带个“root”，就想当然地以为它是最先运行的、适合做初始化。结果脚本一跑，连最基本的file_get_contents都报错，排查半天才发现是路径或者自动加载的问题。理解每个钩子的确切执行时机，这才是关键所在。