路由404主因是缓存未更新或加载异常：需执行php bin/console cache:clear --no-warmup && php bin/console cache:warmup，并确认环境配置、注解启用、路径匹配及OPcache/Docker等外部因素。
路由明明写了却返回404：先确认缓存是否生效
Symfony默认开启路由缓存，开发时改了config/routes.yaml或注解路由，不清理缓存就看不到效果。这不是代码写错了，是缓存没更新。
- 开发环境（
APP_ENV=dev）也会缓存路由，只是自动刷新机制较弱；一旦你改过kernel.php或启用了cache.adapter.filesystem，手动清缓存就是必须步骤 -
php bin/console cache:clear不一定够——它清的是全量缓存，但路由缓存可能被单独写入var/cache/dev/srcApp_KernelDevDebugContainer.php这类文件，更稳妥的是加--no-warmup再单独刷路由 - 执行
php bin/console debug:router后发现你的路由根本不在列表里？基本可以锁定是缓存/加载问题，不是路由语法错误
清除路由缓存的正确命令组合
别只跑cache:clear，它不保证路由定义被重新解析。真正起效的是触发路由编译流程。
- 最简方式：
php bin/console cache:clear --no-warmup && php bin/console cache:warmup—— 先清空，再让容器重建，强制重读所有路由配置 - 如果用的是注解路由（比如
@Route），确保annotations: true在config/packages/framework.yaml里已启用，否则debug:router压根不会扫描控制器类 - 自定义路由加载器（如实现
LoaderInterface）出问题时，cache:warmup会静默失败，此时要加-vvv看报错：php bin/console cache:warmup -vvv 2>&1 | grep -i route
常见误判场景：不是缓存，是路由没匹配上
清完缓存还是404？可能是请求路径和路由定义对不上，而不是缓存没清干净。
- 检查
php bin/console debug:router输出中，你的路由是否带^/api/users$这种正则前缀——如果实际访问的是/api/users/（结尾多斜杠），而路由没声明trailing_slash_on_root: true或没配requirements: { _route: ".*" }，就会404 - 环境变量影响：生产环境（
APP_ENV=prod）下，config/routes/prod/目录会被优先加载，如果你把新路由写在dev/目录下，它在prod里根本不存在 - 权限问题：
var/cache目录属主不对（比如用root跑过命令），导致web server无法读取新生成的路由缓存文件，现象就是清了缓存也没用——检查var/cache/prod/srcApp_KernelProdContainer.php时间戳和权限
为什么cache:clear有时不生效
因为Symfony 5.4+ 和 6.x 的缓存结构变了，cache:clear 默认只删var/cache/*，但某些部署方式（如Docker volume挂载、APCu共享内存）会让旧路由定义残留在PHP OPcache或外部缓存层里。
- OPcache未重置：改完PHP文件后，即使缓存清了，OPcache仍可能返回旧的
srcApp_KernelDevDebugContainer.php字节码，需重启PHP-FPM或执行opcache_reset() - Docker场景下，
var/cache若挂载为volume，本地rm -rf var/cache/*可能没同步到容器内，必须进容器执行php bin/console cache:clear - 使用
SymfonyCloud或Platform.sh时，缓存清理由部署钩子控制，本地执行命令无效，得看.platform.app.yaml里有没有hooks: deploy: 'php bin/console cache:clear'
路由404最耗时间的地方，往往不在写法本身，而在你以为“已经清了缓存”——其实OPcache、Docker volume、环境隔离或者loader加载顺序，任何一个环节卡住，都会让你对着正确的路由配置干瞪眼。
