上线、CI/CD或新环境部署时必须用composer install；它严格按composer.lock安装精确版本，确保环境一致；composer update则忽略lock，重算依赖并升级，仅限本地主动升级且需人工审查变更。

composer install 和 composer update 到底该用哪个

上线、CI/CD 或新环境部署时，composer install 是唯一安全的选择；composer update 只应在明确要升级依赖、且已人工审查变更时使用。

根本区别在于：composer install 完全忽略 composer.json 的版本约束，只按 composer.lock 中记录的精确版本安装；而 composer update 会丢弃 lock 文件内容，重新解析 composer.json 并生成新的依赖树——哪怕只是 minor 版本升级，也可能引入破坏性变更（比如某包 v3.2.0 移除了一个被你直接调用的私有方法）。

• CI 流水线里漏掉 ls -la composer.lock 检查步骤，或缓存了旧 lock，会导致装出和本地不一致的依赖
• Git 提交前没运行 composer update 就改了 composer.json？别人 composer install 会失败，因为 lock 里没对应版本
• 想试某个包的新版？用 composer update vendor/package-name 精确更新，避免连带升级其他包

require 和 require-dev 的边界必须划清

错放依赖不是“多装点东西”，而是直接导致生产环境行为异常或启动失败。

require 里只放运行时真正需要的库：比如 doctrine/dbal（迁移执行必需）、symfony/http-foundation（请求响应核心）；require-dev 放纯开发期工具：比如 phpunit/phpunit、laravel/pint、roave/security-advisories（它本身不提供代码，只做安装拦截）。

Discussion Composer

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

下载

• composer install --no-dev 会跳过 require-dev，但某些包（如日志驱动切换逻辑）若靠 dev 包触发，线上就可能缺功能
• 把 symfony/var-dumper 放进 require？生产环境会多装几十 MB 无用代码，还可能因扩展缺失（如 ext-intl）导致 fatal error
• 区分依据不是“我本地用了”，而是“这个类在 production request 生命周期里是否会被 autoload 并执行”

composer.lock 被忽略或没提交 = 项目失去一致性保障

这不是“可能出问题”，是“一定出问题”：只要 .gitignore 里写了 composer.lock，或者有人没 git add composer.lock，所有后续 composer install 都会回退到默认解析逻辑，装出不可控的版本组合。

尤其在 GitLab CI 或 GitHub Actions 中，常见陷阱是缓存策略误命中原先未提交的 lock，导致构建成功但线上崩溃——因为本地开发环境碰巧装到了兼容版本，而 CI 机器装到了另一个分支。

• 执行 composer diagnose 会检查 lock 是否存在、是否被 git 忽略、PHP 平台要求是否匹配
• CI 步骤开头加一句 test -f composer.lock || (echo "ERROR: composer.lock missing" && exit 1) 能提前拦截
• 团队规范必须写死：每次 composer update 后，composer.lock 必须随 composer.json 一起 commit

autoload 性能优化不能只靠 dump-autoload --optimize

composer dump-autoload --optimize 生成 classmap 是有效手段，但真正拖慢 autoloader 的，往往是 PSR-4 配置不合理。

比如把 "App\": "src/" 这样宽泛的映射写进 autoload，而 src/ 下混着 config/、migrations/、fixtures/ 等非类文件目录，自动加载器每次找类都要扫描整个树——哪怕你只用了一个 AppUser。

• 拆分路径：把核心类限定在 "App\": "src/App/"，配置类单独用 "App\Config\": "src/config/"
• 对单文件类（如 src/Helpers/Str.php），用 classmap 显式声明，避免目录扫描
• composer dump-autoload -a（--classmap-authoritative）会让 autoloader 完全跳过文件系统查找，但要求所有类都已在 classmap 中——漏一个就会 Class not found

复杂点在于：lock 文件一致性、dev/require 划分、autoload 路径设计，这三件事互相咬合。改错一个，另外两个就容易暴露问题。