不能。autoloader-suffix 是静态配置项，仅在 dump-autoload 时读取，不支持环境变量或命令行覆盖；需写死在 composer.json 中，多环境须靠构建脚本替换配置后再执行 dump-autoload。
composer.json 里 autoloader-suffix 能不能用变量或命令行动态覆盖
不能。Composer 的 autoloader-suffix 是静态配置项，只在 dump-autoload 阶段读取一次，不支持环境变量插值、composer install --with-suffix=xxx 这类运行时覆盖。
常见错误现象是：在 CI/CD 中尝试用 COMPOSER_SUFFIX=prod composer install 期望生成不同后缀的 autoloader，结果生成的 vendor/autoload_*.php 文件名和内容完全没变——因为 Composer 根本不解析环境变量。
- 必须显式写死在
composer.json的"config": {"autoloader-suffix": "MyAppProd"}里 - 若需多环境差异化，得靠构建脚本先替换
composer.json再执行composer dump-autoload - 注意：修改后缀会改变
vendor/autoload.php的文件路径和内容哈希，OPcache 缓存键随之变化，这是它防冲突的原理
为什么加后缀能缓解 OPcache 冲突
PHP 的 OPcache 对 include 或 require 的文件路径做缓存键，而 Composer 默认生成的 vendor/autoload.php 是固定路径、固定文件名。当多个项目共用同一份 OPcache（如共享 PHP-FPM pool），它们的 autoload 文件会互相覆盖或误命中。
加了 autoloader-suffix 后，Composer 会生成类似 vendor/autoload_mysuffix.php，路径唯一，OPcache 自然隔离。
- 后缀不影响类加载逻辑，只改生成文件名和内部命名空间别名（如
ComposerAutoloaderInitMyAppProd） - 性能无损耗：文件 I/O 和解析开销几乎一致，只是多了一层命名区分
- PHP 7.4+ 下若启用
opcache.validate_timestamps=0，不加后缀就极易出问题——旧 autoload 文件被缓存，新依赖无法生效
composer dump-autoload 加 --classmap-authoritative 和后缀一起用要注意什么
两者可以共存，但顺序和效果有隐含依赖：后缀影响的是最终生成的入口文件名，而 --classmap-authoritative 影响的是内部 classmap 的生成逻辑。如果同时启用，classmap 仍会被写入带后缀的 autoloader 初始化代码中。
- 必须先设好
autoloader-suffix，再运行composer dump-autoload --classmap-authoritative，否则后缀不生效 - 生成的
autoload_*.php文件里，getLoader()返回的 Loader 实例会包含完整 classmap，且跳过文件系统扫描——这正是防 OPcache 错乱的关键：避免 runtime 扫描触发文件 stat 变更 - 容易踩的坑：本地开发开了
--optimize-autoloader但没加后缀，上线部署却加了后缀，导致 classmap 路径引用不一致，报Class not found
部署时如何安全切换 autoloader 后缀而不中断服务
不能直接替换 vendor/autoload.php，因为 PHP-FPM 可能正从 OPcache 里执行旧版本。必须让新后缀文件完全就位、再原子切换入口引用。
- 步骤是：1）用新后缀跑
composer dump-autoload→ 生成vendor/autoload_newsuffix.php；2）更新应用入口（如index.php）中的require行，指向新路径；3）最后一步才删旧文件或重命名 - 如果用 symlink 部署（如
current → release-20240501），后缀应嵌入 release 目录名，而非靠动态生成——这样每次发布都是全新路径，天然隔离 OPcache - 最易忽略的一点：Web 服务器或 CLI 脚本可能硬编码了
vendor/autoload.php路径，这类地方必须同步检查，否则切了后缀却还在加载旧文件
