Composer 不会自动编译 C 扩展，仅校验扩展是否已加载；编译需在构建流程中手动完成，二进制分发须预编译并正确声明路径。
Composer 不会、也不能自动编译 C 扩展源码——这是必须由开发者或部署环境主动完成的系统级操作。所谓“自动化编译”，本质是绕过 Composer，把编译逻辑下沉到构建流程中；而“二进制分发”则依赖预编译产物 + 正确的 bin 或 ext-* 声明配合。
为什么 composer install 从不触发 C 扩展编译
Composer 的职责边界非常明确：解析依赖树、下载 ZIP/TAR 包、解压、写 autoload、校验 ext-* 是否已加载。它不调用 phpize，不执行 make，也不检查 GCC 是否可用。一旦你在 composer.json 中写了 "ext-somecext": "*"，它只做一件事：运行 extension_loaded('somecext')。失败就报错：PHP extension "somecext" is missing。
- 即使依赖包的
composer.json里定义了"scripts": {"post-install-cmd": "make && sudo make install"}，该命令也不会被自动执行——post-install-cmd默认禁用，需显式加--no-dev或手动运行composer run post-install-cmd - CI/CD 环境中若未预装
php-dev、gcc、make，任何试图在post-install-cmd里编译的行为都会失败，且污染整个composer install流程 - 扩展编译结果（
.so文件）路径依赖 PHP 的extension_dir，而该路径在不同系统、不同 PHP 安装方式下差异极大，无法靠 Composer 统一推导
如何让含 C 源码的包支持可复现的二进制分发
核心思路是：把 C 扩展当作“构建产物”而非“源码依赖”来管理。包作者应在发布前完成编译，并将 .so 文件（或对应平台的 DLL / DYLIB）放入 dist/ 目录，再通过 composer.json 的 bin 或自定义安装脚本暴露使用入口。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 包作者必须在 Git tag 前运行完整构建链：
phpize && ./configure && make && cp modules/somecext.so dist/，然后提交dist/somecext.so到仓库 - 用户端无需编译，只需在
php.ini中启用：extension=/path/to/vendor/vendor-name/package-name/dist/somecext.so（注意路径需绝对或相对于extension_dir） - 若想简化启用流程，可在包中提供一个 PHP 脚本（如
bin/install-extension.php），内容为复制dist/下的.so到系统extension_dir并输出修改php.ini的提示——这个脚本需声明在bin字段，供用户手动运行 - 不要在
autoload中尝试dl()动态加载（PHP 8+ 已废弃），也不要依赖extension=的相对路径，它在 CLI 和 Web SAPI 下行为不一致
容器化与 CI 中的可靠集成方式
在 Docker 或 GitHub Actions 中，C 扩展的安装必须与 PHP 运行时绑定，不能交给 Composer 代理。典型做法是分层构建，把扩展编译固化在基础镜像里。
- Dockerfile 中应先安装构建工具和 PHP 头文件：
RUN apt-get update && apt-get install -y php-dev gcc make - 接着用
pecl install或源码编译，最后清理构建依赖：RUN pecl install redis && docker-php-ext-enable redis && apt-get purge -y php-dev gcc make - CI 脚本中避免
composer install --ignore-platform-reqs掩盖缺失扩展的问题——它只是跳过检查，运行时仍会因extension_loaded()失败而崩溃 - 若使用多阶段构建，确保最终镜像中
php -m | grep somecext可查到扩展名，而不是仅靠ls vendor/...判断
真正容易被忽略的是：C 扩展的 ABI 兼容性。同一个 .so 文件不能跨 PHP 主版本（如 8.1 → 8.2）或 SAPI 类型（CLI → Apache）复用。哪怕你成功分发了二进制，也得确保它和目标环境的 PHP 编译参数（ZTS、debug mode、iconv 实现等）完全一致——这正是 Conan 那类工具存在的理由，而 Composer 无意也无力覆盖这一层。
