Composer不安装C扩展，仅在install/update时用extension_loaded()检查其是否存在；未加载则报错中断，且不验证版本或ABI兼容性。
Composer 本身不感知、也不处理任何内核模块（如 Linux kernel module、PHP 扩展的 .so/.dll 文件）的编译、加载或分发。它只管 PHP 包（即 composer.json 描述的代码包）的下载、解压、版本解析和自动加载。所谓“特定内核模块需求”，实际是运行时环境约束，必须由外部机制承接——Composer 只能间接配合。
为什么 composer install 不报错，但 runtime 却提示 extension not loaded
常见现象：项目 require 了 ext-redis 或 ext-swoole，composer install 成功，但 PHP 启动时报 Class 'Redis' not found 或 extension 'swoole' not loaded。
- Composer 仅检查
php -m输出中是否存在该扩展名（通过ext-xxx约束），不验证其是否真正可用（比如是否 ABI 兼容、是否启用、是否被 disable_functions 拦截） - 这个检查发生在
install/update阶段，且默认只做一次；若你中途手动改了php.ini，Composer 不会重检 -
ext-xxx是 platform requirement，不是包依赖——它不会出现在vendor/里，也不会被 autoload 加载
如何在 composer.json 中正确声明内核级依赖
用 config.platform.ext-xxx 强制覆盖检测结果，或用 require + provide 组合表达兼容性意图：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 若你打包的是一个「预编译二进制扩展」（如
swoole.so），应在自己的包里写："provide": { "ext-swoole": "5.1.0" }，让其他包能按扩展名依赖你 - 若你部署环境已固定（如 Docker），可在
composer.json顶层加："config": { "platform": { "ext-redis": "5.3.7", "ext-mbstring": "8.1.0" } }——这会让 Composer 跳过真实检测，直接按你写的版本号解析依赖 - 不要写
"require": { "ext-redis": "^5.0" }然后指望 Composer 帮你装 redis.so；它只会校验当前 PHP 是否满足，不执行安装动作
私有包分发含内核模块时的典型陷阱
你发布了一个包 myorg/php-extension-wrapper，内部封装了自研 mykernel.ko 的用户态接口，并要求系统已加载该模块。这时：
- 不能把
.ko文件塞进dist.zip并期望composer install自动insmod——Composer 没有 root 权限，也不执行 shell 命令 - 若用
scripts在post-install-cmd里调sudo insmod，CI 环境大概率失败（无 sudo、无 /lib/modules/$(uname -r)） - 真正可行的做法是：把模块加载逻辑下沉到部署脚本（Ansible / Dockerfile / systemd unit），而 Composer 包只负责提供 PHP 接口层，并用
extension_loaded('mykernel')在运行时兜底报错
最常被忽略的一点：Composer 的 platform 配置和 ext-xxx 检查，只影响依赖解析阶段；它既不修改 php.ini，也不触发 dl() 或 extension_dir 扫描。所有“内核模块需求”最终都得靠运维侧闭环，Composer 只能当个带嘴的提醒者。
