composer仅实现psr-4自动加载，不发明psr规范；配置需严格满足命名空间末尾双反斜杠、路径结尾正斜杠、大小写敏感等硬性规则，且修改后必须执行composer dump-autoload才生效。
PSR 规范不是 Composer 发明的，Composer 只是实现了 PSR-4（和 PSR-0）自动加载规则；你写错 namespace 或路径，composer dump-autoload 不报错，但运行时一定 Class not found。
PSR-4 映射必须满足“命名空间 → 目录”的严格对应关系
PSR-4 不是“把类名转成文件路径”的模糊猜测，而是硬性约定：类 popplibraryLibraryCatalogue 必须存在于 mylib/LibraryCatalogue.php，且该文件里必须声明 namespace popplibrary;。Composer 不会帮你补全命名空间，也不会忽略大小写。
-
"psr-4": {"popp\library\": "mylib/"}✅ 路径末尾有/，namespace 末尾有 -
"psr-4": {"popp\library": "mylib"}❌ 缺少反斜杠，Composer 解析时可能误判为popplibrarySomeClass→mylib/SomeClass.php（实际应为mylib/SomeClass.php，但命名空间不匹配仍失败） -
"psr-4": {"App\": "./src/"}❌./是多余符号，路径始终相对于composer.json所在目录，直接写"src/"即可 - Windows 下也必须用正斜杠
/，不要写双反斜杠\或单反斜杠（后者在 JSON 字符串中会被当转义符处理）
改完 autoload 后不执行 dump-autoload = 白配
Composer 不会在每次 require 'vendor/autoload.php' 时重新读取 composer.json 中的 autoload 配置。它只在 install、update 或显式调用 dump-autoload 时，把映射规则编译进 vendor/autoload.php 里的静态数组。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 新增一个
src/Helper.php并配好"App\": "src/"，不跑composer dump-autoload→new AppHelper()必然报错 - 加
-o参数可生成优化版映射：composer dump-autoload -o，适合生产环境（跳过动态查找，直接查表） - 如果用了 classmap，路径必须真实存在且可读；否则
dump-autoload会静默跳过，不提示、不报错、也不生成条目
files 自动加载别塞重逻辑
"files" 列表里的 PHP 文件，会在每次请求时被 include_once 执行——它不走类加载流程，只做全局函数/常量引入。
- 适合放
src/functions.php这类定义str_slug()等辅助函数的文件 - 千万别往里写数据库连接、Redis 初始化、配置加载等耗时操作——它们会在每个 HTTP 请求里重复执行
- 不要用
files替代psr-4：比如把AppHelper的类定义直接扔进functions.php，会导致命名空间失效、IDE 无法识别、测试难 mock
最常被忽略的一点：PSR-4 的路径和 namespace 是“双向绑定”，改了任一端都得同步验证。本地能跑 ≠ 上线能跑，因为开发环境可能已缓存旧映射，或误装了 dev 包掩盖了 autoload 问题。上线前务必用 composer install --no-dev && php -r "new AppService();" 实测关键类是否可实例化。
