composer.lock更新后白屏主因是自动加载未同步，必须执行composer dump-autoload -o生成静态映射并清空框架缓存与OPcache。
composer.lock 更新后白屏，基本不是前端代码问题，而是自动加载、缓存或配置没跟上更新节奏——尤其常见于 Symfony、Laravel 等依赖容器和配置驱动的框架。
composer dump-autoload -o 必须执行，否则新类根本找不到
composer.lock 变了，意味着 vendor 里可能新增/删减了类文件。但 PHP 的自动加载器（autoload）不会自动感知这些变化，它只认 vendor/autoload.php 里注册的映射表。
- 没执行
composer dump-autoload -o：新引入的类、命令、事件监听器等，运行时直接报Class "App\Command\DeployCommand" not found -
-o（optimize）参数不能省：它生成静态映射，比 PSR-4 动态查找快 3–5 倍，且能暴露路径注册错误（比如命名空间与目录结构不一致） - 某些框架（如 Laravel）在生产环境会跳过 autoload 重生成，所以本地正常、线上白屏，大概率卡在这一步
cache:clear 必须清全环境，别只清 dev
框架缓存（如 Symfony 的 var/cache）是按环境+PHP 版本+依赖哈希生成的。composer.lock 一变，哈希就变，旧缓存立刻失效——但框架不会主动删它，而是静默 fallback 到错误状态，最终白屏。
- Symfony：必须跑
php bin/console cache:clear --no-warmup（加--no-warmup避免因类未加载而中断），再补php bin/console cache:warmup - Laravel：用
php artisan config:clear && php artisan cache:clear && php artisan view:clear，别只清config:clear - 如果用了 OPcache，还得加
opcache_reset()或重启 PHP-FPM，否则旧字节码还在执行
config:dump-reference 或 lint:container 必须跑，大版本升级后配置键名常被删
依赖升级常伴随配置废弃。比如 Symfony 6.3 移除了 framework.session.cookie_secure，改用 cookie_samesite；Laravel 11 把 app.key 验证逻辑收紧。白屏前控制台可能没报错，但容器编译阶段已失败。
- Symfony：执行
php bin/console config:dump-reference framework对照当前config/packages/framework.yaml，看是否有字段标为DEPRECATED - 更狠的是
php bin/console lint:container：它会真正加载整个服务容器，把所有class not found、argument type mismatch、invalid service definition全部吐出来 - 别信文档“向后兼容”——很多包在 minor 版本里悄悄改了接口契约，
composer update后第一次容器编译才暴露
白屏时 Network 面板里 200 HTML + 404 JS 是典型标志
这不是前端构建问题，而是 public/index.php 能跑，但路由或资源加载失败。常见于 publicPath 错配、CDN 缓存旧 HTML、或 Nginx 未正确 fallback。
- 打开 DevTools → Network，刷新：若
index.html是 200，但main.js或runtime.js返回 404 或 200 HTML 内容（看到），说明 publicPath 指向了错误路径 - 检查
composer.json里是否误加了"extra": {"public-dir": "public"}类配置，干扰了框架默认行为 - Nginx 配置里
try_files $uri $uri/ /index.php?$query_string;缺失，会导致 SPA 路由下子路径 JS 请求被当静态资源处理
真正麻烦的不是 composer.lock 变了，而是它触发了一连串隐式依赖：自动加载映射、容器定义、配置解析、OPcache 字节码——每个环节都可能静默失败。白屏只是最后表现，得一层层往回敲，而不是盯着 console 里有没有红字。
