post-install-cmd可在依赖真正安装时触发系统命令，需封装为独立脚本（如bin/reload-php-fpm.sh），配合环境判断、配置校验（php-fpm -t）和systemctl reload等安全操作，严禁直接写sudo或裸命令。
Composer install 后如何触发系统命令
Composer 本身不提供“安装完自动重启服务”的能力，但支持通过 scripts 配置项在生命周期钩子中执行自定义命令。关键不是“能不能”，而是“在哪一环执行才安全”——post-install-cmd 和 post-update-cmd 是最常用、也最稳妥的选择。
直接写 systemctl restart php-fpm 很危险：权限不足、服务名不一致、甚至可能中断正在处理的请求。必须加判断和降级逻辑。
- 优先用
post-install-cmd（仅新装依赖时触发），避免每次composer update都重启 - 脚本应先检测 PHP-FPM 当前状态：
systemctl is-active --quiet php8.1-fpm，再决定是否 reload 而非 restart - 生产环境强烈建议用
reload（平滑重载配置）而非restart（强制终止进程） - 若 PHP-FPM 运行在非 systemd 环境（如 Docker 或 init.d），需改用对应命令，例如
/etc/init.d/php8.1-fpm reload
composer.json 中的 scripts 怎么写才可靠
scripts 区块里不能直接写多条 shell 命令，必须封装成可执行单元。推荐写成独立脚本文件（如 bin/reload-php-fpm.sh），再在 composer.json 中调用——这样便于测试、加日志、做权限检查。
示例 composer.json 片段：
立即学习“PHP免费学习笔记（深入）”；
"scripts": {
"post-install-cmd": [
"bash bin/reload-php-fpm.sh"
]
}
注意：不要写成 "post-install-cmd": "bash bin/reload-php-fpm.sh"，因为 Composer 会把整个字符串当一个命令执行，无法处理空格和参数分隔。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
bin/reload-php-fpm.sh必须有可执行权限：chmod +x bin/reload-php-fpm.sh - 脚本开头加上
#!/usr/bin/env bash，避免因默认 shell 不兼容出错 - Composer 执行脚本时工作目录是项目根目录，路径要用相对或绝对方式写清楚
- 别在脚本里用
sudo—— 应让部署用户具备免密执行systemctl reload的权限（通过visudo配置）
reload-php-fpm.sh 脚本要检查哪些实际条件
一个能上线的脚本，至少得回答三个问题：当前是不是生产环境？PHP-FPM 配置有没有语法错误？有没有权限 reload？漏掉任意一条，都可能导致服务不可用。
简版脚本核心逻辑如下（省略日志和错误退出细节）：
#!/usr/bin/env bash if [ "$APP_ENV" != "prod" ]; then echo "Skip PHP-FPM reload: not in prod environment" exit 0 fi <h1>检查 php-fpm 配置语法</h1><p>if ! php-fpm -t &>/dev/null; then echo "PHP-FPM config test failed — aborting reload" exit 1 fi</p><h1>尝试 reload，失败时输出具体错误</h1><p>if ! systemctl reload php8.1-fpm 2>&1 | grep -q "failed"; then echo "PHP-FPM reloaded successfully" else echo "Failed to reload PHP-FPM" exit 1 fi</p>
-
$APP_ENV应由部署流程注入（如APP_ENV=prod composer install），不能硬编码 -
php-fpm -t是关键守门员，配置写错却强行 reload，会导致服务直接挂掉 -
systemctl reload失败时，$?不一定非零，所以要用grep -q "failed"辅助判断 - 别忽略
2>&1，否则 stderr 错误信息会直接打到终端，CI/CD 流程里看不到
为什么不用 supervisor 或 inotifywait 替代
有人想监听 vendor/ 目录变化来触发 reload，这在开发机上看似可行，但在真实部署场景下完全不可靠。
Composer 安装过程本身是原子操作：先下载解压到临时目录，再 mv 替换 vendor。inotify 可能捕获到中间状态，导致 reload 发生在文件未就绪时；supervisor 更适合长进程管理，对一次性事件响应滞后且难调试。
- Composer 的
post-*钩子是唯一能 100% 确保“依赖已就位、代码已生效”的时机 - 所有自动化动作必须与部署流程对齐，而不是绕过它去监听文件系统
- 如果用了容器化部署（Docker），根本不需要 reload —— 整个 PHP-FPM 进程随容器重建，脚本逻辑要彻底重构
真正容易被忽略的点是：reload 成功不代表新代码立刻生效。OPcache 缓存、APCu、甚至某些框架的编译缓存，都可能让旧类继续运行。这类问题不会报错，只能靠监控和主动清理策略兜底。
