Symfony路由requirements正则仅在匹配阶段生效，若泛型路由（如/{page}）定义在前且无约束，会吞噬所有路径导致带正则的路由不触发；URL生成不受其限制，非法值仍可生成链接但访问返回404。
直接说结论：Symfony 6.x 的路由参数和正则匹配不是“学完就懂”的概念，而是“用错一次就 404 或 500”的实操环节。关键不在语法多复杂，而在 requirements 的正则是否真正生效、是否和路由顺序/默认值冲突、是否在生成 URL 时被忽略。
为什么 requirements 写了却没效果？
最常见的假象是：你写了 requirements={"slug"="[a-z0-9-_]+"}，但访问 /blog/abc! 还是进了控制器——这不是 Symfony 没生效，而是你没触发它真正起作用的条件。
- Symfony 只在「路由匹配阶段」校验
requirements，不拦截请求也不抛异常；匹配失败时直接跳过该路由，继续往下找 - 如果你的路由定义在泛型路由（如
/{page}）之后，而泛型路由又没加requirements，那所有路径都会被它吃掉，根本轮不到你的带正则的路由 -
requirements不影响url()或path()生成链接——哪怕你传入非法值，URL 照样生成，只是访问时 404 - 正则必须完整匹配整个参数值，
"[a-z]+"不会匹配"abc123"，得写成"[a-z0-9]+"
^((?!login).)*$ 这类负向断言能用，但有坑
想排除 /login、/admin 等固定路径？用负向先行断言看起来很酷，但实际部署中容易翻车。
在SEO发布前，从路由清单生成XML网站地图和robots.txt
下载
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- PHP PCRE 默认不启用
u（UTF-8）修饰符，含中文或 emoji 的路径可能意外匹配失败 -
^((?!abc).)*$在长路径下性能明显下降，尤其当参数值超过 50 字符时，回溯可能指数级增长 - Symfony 6.3+ 对某些复杂正则会静默截断或报
Symfony\Component\Routing\Exception\InvalidParameterException，但错误信息不提示具体哪条路由出问题 - 更稳的做法是：把
/login、/register这类路由放在最前面，靠顺序优先级拦截，而不是全靠正则“筛”
多域名路由里 {domain} 怎么配才不踩空
用 host="{domain}" + requirements={"domain"="..."} 支持多个品牌域名时，最容易漏掉两件事：
-
host参数必须出现在路由定义里，不能只靠defaults或中间件“后期注入”——否则UrlGenerator根本不知道该填哪个 host - 正则里的点号
.必须转义，"service\.main-domain\.tld"才对；写成"service.main-domain.tld"会匹配任意字符，变成通配符 - 多个域名用
(?:...|...|...)包裹，别用|直连——"a\.tld|b\.tld"在某些 PCRE 版本里会被解释为 “a.tld” 或 “b.tld” 前面任意字符 - 本地开发时，
localhost或127.0.0.1不在正则里？记得加进去，否则php bin/console server:run下完全跑不通
真正麻烦的不是写对一条路由，而是当你改了某个 requirements，发现线上部分 URL 生成失效、部分页面 404、日志里又没明确报错——这时候得去翻 cache/prod/srcApp_KernelProdContainer.php 里实际编译出的路由规则，而不是只看注解。
