必须用独立PHP脚本生成healthcheck.sh而非直接在composer.json中写命令；自测应验证autoload.php、核心扩展、配置文件、缓存目录等基础可用性，避免数据库连接和phpunit；脚本需POSIX兼容并注明Windows运行方式。
composer install 后怎么自动触发自测脚本
不能靠 Composer 自带的 scripts 钩子直接生成可执行脚本文件——它只支持运行已有命令，不支持写入新文件。必须把“生成脚本”这步拆出来，用 shell 命令或 PHP 脚本完成。
推荐做法：在 composer.json 的 post-install-cmd 或 post-update-cmd 中调用一个本地 PHP 脚本（比如 bin/generate-healthcheck.php），由它输出 healthcheck.sh 到项目根目录。
- 确保
bin/目录存在且可写，否则脚本会因权限失败 - 不要在钩子里直接用
echo "..." > healthcheck.sh—— Windows 和 Linux 换行符、路径分隔符不一致，容易出错 - PHP 脚本里用
file_put_contents()写入，并显式指定PHP_EOL保证换行兼容
自测脚本该检查哪些关键项
环境自测不是跑全量测试，而是验证基础可用性。重点覆盖 Composer 安装后最可能出问题的环节：
-
vendor/autoload.php是否存在且可 require（防止 autoloader 损坏） - 核心依赖是否能正确加载，例如
new PDO('sqlite::memory:')或json_encode([])（验证扩展是否启用） - 配置文件是否存在，比如
config/app.php或.env（避免部署遗漏） - 缓存目录是否可写（
storage/cache或var/cache）
别加数据库连接测试——它依赖外部服务，不属于“环境自测”范畴；也别调用 phpunit，那是开发阶段的事。
如何让生成的 healthcheck.sh 具备跨平台基础能力
Linux/macOS 上直接 sh healthcheck.sh 没问题，但 Windows 用户默认没有 sh。所以脚本开头要加 shebang 并说明运行方式：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
#!/usr/bin/env bash # 使用方式：Linux/macOS 执行 ./healthcheck.sh；Windows 请用 Git Bash 或 WSL 运行
脚本内部避免使用高级 bash 特性（如 [[、数组、mapfile），全部用 POSIX 兼容语法：
- 用
[ -f "$file" ]而非[[ -f $file ]] - 用
command -v php查 PHP 是否在 PATH 中，而不是which php（macOS Catalina+ 默认禁用 which） - 错误退出统一用
exit 1，成功用exit 0，方便 CI 工具判断
为什么不能把自测逻辑直接塞进 composer.json 的 scripts
因为 composer.json 的 scripts 字段本质是命令列表，不是编程环境。你没法在里面做条件判断、变量拼接、文件写入等操作。例如下面这段是无效的：
"scripts": {
"post-install-cmd": "echo '#!/bin/sh\necho OK' > healthcheck.sh && chmod +x healthcheck.sh"
}实际执行时，Composer 会把整条字符串当做一个命令传给 shell，但不同系统对引号、重定向、多命令分隔符（&&）解析不一致，极易失败。更麻烦的是，如果 healthcheck.sh 已存在且被 git 忽略，这条命令还可能静默失败。
真正可靠的做法，永远是把逻辑封装成独立可执行文件（PHP 或 bash），再由 Composer 钩子调用它——边界清晰，调试方便，也便于后续加日志或参数控制。
