PSR-4规范是Composer自动加载的强制前提，非选配；其生效严格依赖命名空间前缀、目录路径、文件名大小写三要素完全匹配，且必须执行composer dump-autoload更新映射，否则类必然找不到。

直接说结论：PSR 规范不是“选配”，而是 Composer 能正常工作的前提；不按 PSR-4 配 autoload，vendor/autoload.php 就只是个空壳——类找不到、测试跑不了、CI 直接挂。

为什么 require_once 'vendor/autoload.php' 后还是 Class not found

根本原因几乎全是 autoload 配置没对上实际文件结构。PSR-4 不是“写完命名空间就自动认路”，它严格依赖三要素匹配：命名空间前缀 + 目录路径 + 文件名大小写。

• composer.json 里写的 "App\": "src/"，但类文件放在 src/app/Controller.php → 命名空间得是 AppController，不是 appController（首字母必须大写）
• 类文件名是 UserModel.php，但类声明是 class Usermodel → PSR-4 要求类名与文件名完全一致（含大小写），否则自动加载失败
• 改了 composer.json 的 autoload，但没运行 composer dump-autoload → 配置不会生效，vendor/autoload.php 仍用旧映射
• 用了 "psr-4": {"": "src/"} 这种通配配置 → 看似灵活，实则绕过命名空间校验，上线后容易因同名类冲突或路径歧义导致不可复现的加载错误

composer install 和 composer update 必须分清场景

这两个命令行为差异极大，混用等于主动制造环境不一致。

Discussion Composer

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

下载

• 新拉代码、CI/CD 构建、线上部署 → 只能用 composer install，它严格按 composer.lock 安装，确保所有人得到完全相同的依赖树
• 本地加新包（如 monolog/monolog）→ 用 composer require monolog/monolog，它会自动执行 update 并更新 lock 文件
• 想升小版本（比如 symfony/http-foundation 从 6.3.0 升到 6.3.5）→ 用 composer update symfony/http-foundation --with-dependencies，避免裸跑 update 把其他包也带崩
• 误删 vendor 和 composer.lock 后只跑 update → 极大概率装出一堆新版包，引发 Method not found 或 ArgumentCountError

云原生构建中 autoload 的致命陷阱

Docker 多阶段构建里，PSR-4 路径错位是 Class not found 最隐蔽的来源——不是代码错了，是镜像里根本没那个目录。

• "psr-4": {"App\": "src/"} 要求运行时 src/ 目录存在且可读；但 Dockerfile 若只 COPY --from=builder /app/src/ .，漏了 src/Controller/ 子目录，类就永远加载不到
• 开发用 PSR-4，构建时却忘了加 composer dump-autoload --classmap-authoritative → 容器启动时仍尝试扫描 src/ 下所有 PHP 文件，而该目录在 Alpine 镜像里可能被精简掉了
• 在 autoload 里混用 "files" 类型（如 "files": ["src/helpers.php"]）→ 这类文件每次请求都 require，无法被 opcache 预加载，且挂载卷覆盖后内容不一致，调试时行为飘忽
• 生产构建必须加 --optimize-autoloader，否则 vendor/autoload.php 里仍是动态查找逻辑，FPM worker 启动慢 20%+，opcache preload 失败

autoload-dev 配置常被当成摆设

很多人把测试类放进 tests/ 就以为万事大吉，但 PHPUnit 找不到测试类，90% 是因为 autoload-dev 没配或配错。

• autoload-dev 不是 autoload 的子集，它独立生效；测试代码用的命名空间（如 AppTests）必须单独映射到 tests/，不能指望主 autoload 覆盖
• 配了 "autoload-dev": {"psr-4": {"App\Tests\": "tests/"}}，但测试类文件放在 tests/Feature/UserTest.php，命名空间却是 AppTestsFeature → 路径和命名空间必须严格对应，少一层 Feature 就加载失败
• CI 中运行 phpunit 报 Class 'AppTestsUserTest' not found → 先检查是否用了 --no-dev 参数（CI 默认加），再确认 autoload-dev 是否生效，最后看 composer dump-autoload 是否重生成了 dev 映射
• 不要在 autoload-dev 里写 "psr-4": {"": "tests/"} → 测试类命名空间一旦不规范，就会污染主 autoload 的后备逻辑，上线后可能意外加载测试代码

最常被忽略的点：PSR-4 的路径映射是静态的，不支持运行时动态调整；所有路径都基于项目根目录解析，__DIR__ 在 vendor/autoload.php 里指向的是 vendor/composer/，不是你的项目根目录——所以入口文件第一行必须是 require __DIR__ . '/vendor/autoload.php';，任何相对路径或硬编码路径都会在 CLI 或子目录访问时失效。