如何利用Composer管理微框架？轻量级项目的构建艺术-composer-PHP中文网

真正决定框架轻重的是删减依赖、精简autoload映射和按需加载；create-project膨胀因骨架预装全套包，应删除未使用的require和require-dev项，优化psr-4映射，生产启用--classmap-authoritative。

如何利用composer管理微框架？轻量级项目的构建艺术

composer 不构建微框架，它只管理你选中的那几个轻量包——真正决定“轻不轻”的，是你删了什么、没装什么、以及类加载路径有没有绕远路。

为什么 create-project 一装就重？

执行 composer create-project slim/slim-skeleton 或 create-project topthink/think 后 vendor 膨胀到 80MB+，不是因为 composer 多装了东西，而是骨架包的 composer.json 里已经写死了全套依赖：monolog/monolog、guzzlehttp/guzzle、phpunit/phpunit、甚至 symfony/var-dumper —— 全部照单全收，不管你的项目只跑一个 GET /health。

关键点在于：create-project 只是复制模板的 composer.json 并运行 install，它不读你的代码，也不猜你用不用。

删掉 require-dev 里的所有包（如 laravel/pint、phpstan/phpstan），除非你真在本地跑静态分析
检查 require 中每个包是否被 grep -r "new |^use" src/ 或 IDE 的 “Find Usages” 找到过；没被引用的，直接删
guzzlehttp/guzzle 这种重型 HTTP 客户端，若只发一两个内部请求，换成 ext-curl + file_get_contents 更省

autoload 怎么配才不拖慢启动？

很多微框架项目跑得慢，不是逻辑复杂，是自动加载映射太宽泛。比如把 "App\": "src/" 写成 "": "src/"，或在 psr-4 里塞了多个根命名空间却只用其中一个。

更隐蔽的问题是：用了 classmap 却没跑 composer dump-autoload --optimize，导致每次请求都遍历整个 src/ 目录找类文件。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

只映射实际用到的命名空间，例如只有路由和控制器，就只配 "App\Http\": "src/Http/"
避免用 files 加载一堆工具函数文件，改用 psr-4 封装成类，按需加载
生产环境必须加 --optimize-autoloader，否则 ClassLoader::findFile() 会反复 stat 文件系统

如何让 require 变成最小可行集？

一个纯响应 JSON 的 API 微服务，require 区域可以精简到 3 行以内。这不是理论，是线上压测验证过的配置：

"require": {
  "php": "^8.2",
  "nyholm/psr7": "^1.8",
  "guzzlehttp/psr7": "^2.6"
}

注意：slim/slim、league/route、fast-route 全都不需要——你可以直接用 $_SERVER['REQUEST_URI'] + switch 分发，或手写 20 行闭包路由调度器。

别为“以后可能用”提前装包，等报 Class not found 再 composer require 更安全
替换重型依赖时，优先选无依赖的 PSR-7 实现（如 nyholm/psr7）而非带一堆 require 的框架封装
如果连 PSR-7 都嫌重，ext-http（已启用时）或原生 cURL + json_encode 足够应付大多数场景

composer install --no-dev 真的够轻吗？

这条命令只是跳过 require-dev，对 require 里本就不该存在的包毫无影响。它解决的是“开发工具没进生产”，不是“生产不该有这些包”。

更麻烦的是：很多人在 CI 中用 composer install --no-dev，却忘了 vendor/autoload.php 仍会加载全部 psr-4 映射路径下的类——哪怕那些类从没被 new 过，只要路径在 autoload 里，PHP 就得预留内存做符号表注册。

确认 composer.json 的 autoload 段已按需裁剪，不是靠 --no-dev 掩盖冗余
上线前跑一次 composer dump-autoload --classmap-authoritative --no-dev，强制关闭动态查找，提升加载确定性
部署包里别留 composer.json 和 composer.lock 原件，它们对运行时零价值，只占磁盘和镜像体积

真正的轻量，藏在你删掉的那几行 require 里，而不是某条命令的参数中。最常被忽略的，是 autoload 映射范围与实际代码结构的偏差——它不报错，但悄悄吃掉内存和启动时间。