反复require 'vendor/autoload.php'会新建多个ClassLoader实例并持续注册，PHP-FPM常驻进程中对象引用累积导致内存只增不减；应确保Web入口仅require一次，避免循环或中间件中重复加载。
PHP-FPM 里反复 require 'vendor/autoload.php' 会怎样
每次 require 'vendor/autoload.php' 都会新建一个 ComposerAutoloadClassLoader 实例，并调用 spl_autoload_register() 注册一套新加载逻辑。在 PHP-FPM 的常驻进程模型下，这些实例不会销毁，对象引用持续累积——内存只增不减。
这不是 Composer 本身泄漏，是你代码触发了它。验证方法很简单：var_dump(spl_autoload_functions())，如果看到多个 ClassLoader::loadClass（且对象 ID 不同），就坐实了问题。
- Web 入口（如
public/index.php）必须只require一次，且不能放在循环或中间件重复执行路径里 - 别在控制器、服务类里偷偷再
require——autoload 已由入口统一加载，二次加载纯属冗余 - 框架集成时留意是否已内置 autoload 加载（如 ThinkPHP 的
start.php），额外require就是双注册
classmap-authoritative 和 --optimize-autoloader 到底怎么配才生效
composer dump-autoload -o 在 Composer 2.0+ 中已不是“生成完整 classmap”的命令，它只是 --classmap-authoritative 的别名，行为已改变：强制跳过 PSR-4 fallback，但不保证 classmap 覆盖全部类。空目录、条件加载的类、"files" 类型引入的辅助函数里 new 出来的类，极易漏进 classmap，部署后报 Class not found。
真正可靠的是这条命令：composer install --optimize-autoloader --no-dev --classmap-authoritative，它是一套协同生效的加固逻辑：
-
--no-dev：跳过所有require-dev包，同时确保它们的autoload-dev规则（比如"Tests\": ["tests/"]）完全不参与 classmap 构建 -
--optimize-autoloader：在 install 阶段真正扫描所有 PSR-4 目录，把匹配类写入vendor/composer/autoload_static.php（Composer 2 默认格式），结构紧凑、OPcache 友好 -
--classmap-authoritative：让 autoloader 完全信任静态映射，删掉所有foreach ($this->prefixesPsr4循环逻辑，只保留if ($classMap = $this->classMap)分支
验证是否生效：打开 vendor/composer/autoload_real.php，如果 findFile() 方法只剩一个 if 分支且无任何 foreach，才算真正“权威”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
opcache_reset() 为什么必须加、什么时候加
启用 opcache 后，autoload_static.php 和 autoload_classmap.php 会被缓存进共享内存，后续请求跳过所有 IO 和字符串匹配——但前提是 opcache 没被污染。
常见陷阱：opcache.enable_cli=1 开启后，CLI 下的 composer install 会把类定义写进 opcache，而 PHP-FPM 进程没调用 opcache_reset()，导致旧类定义长期驻留，新 autoload 无法生效。
- 部署后务必加一句
opcache_reset()（注意权限，仅限 CLI 或管理接口调用） - 不要在每次请求里调用——它会清空整个 opcache，得不偿失
- CI/CD 流程中，应在
composer install后、服务 reload 前执行
APCu 缓存和 classmap-authoritative 能不能一起用
不能。二级优化 A（--classmap-authoritative）和 B（--apcu-autoloader）互斥，需根据项目情况选择其一。
--apcu-autoloader 缓存的是“类是否存在”的判断结果，比 classmap 更轻量，也更安全；但它依赖 APCu 扩展，且只缓存查找结果，不替代 classmap 本身。
- 若项目有运行时动态生成类（如 Laravel 的匿名迁移类、Doctrine 的代理类），选
--apcu-autoloader，避开Class not found风险 - 若项目类结构稳定、无运行时生成类，且追求极致冷启动性能，选
--classmap-authoritative - 两者混用会导致 autoloader 行为不可预测，官方明确不支持
classmap 越大越快？错。若 autoload_classmap.php 达数 MB（常见于误扫 tests/、docs/、examples/），每次请求都要全量 require 进内存，反而拖慢冷启动——精简 PSR-4 映射、显式声明命名空间，比盲目加 -a 更关键。
