Buffalo 的 routes.go 不支持正则路径约束，所有 {param} 均作字符串处理，需在 handler 中手动校验格式，推荐用 pop.ErrInvalidID 处理数字 ID，非数字字段仍需显式验证。
Buffalo 的 routes.go 不支持正则路径约束
Buffalo 的路由器底层用的是 github.com/gorilla/mux，但框架层**完全屏蔽了正则匹配能力**——你不能像原生 mux 那样写 app.Get("/users/{id:[0-9]+}", UsersShow)。所有 {param} 都被当作纯字符串参数处理，路由匹配阶段不校验格式，c.Param("id") 拿到的永远是 raw string。
必须在 handler 里手动校验参数格式
正则校验只能后置到 Action 函数中，靠 regexp.MatchString 或 strconv.ParseUint 等做运行时判断。一旦不合法，应立刻返回 404 或 400，避免后续 ORM 查询失败或 panic。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
c.Param("id")返回空字符串或非数字串时，strconv.ParseUint(c.Param("id"), 10, 64)会报错，别直接传给db.Find() - 对 UUID 路由（如
/posts/{slug}），建议用github.com/google/uuid的Parse判断有效性，而不是模糊匹配长度 - 不要在中间件里统一校验——不同路由的参数名、格式、业务含义完全不同，硬塞进一个中间件反而增加耦合和误判风险
替代方案：用自定义类型 + pop ORM 的 Find 行为兜底
如果你的 ID 字段是 uint64 类型，pop ORM 在调用 tx.Find(&u, c.Param("id")) 时，会自动尝试转换字符串为整数；转换失败就返回 pop.ErrInvalidID。这比手写正则更轻量，也更贴近数据层语义。
- 遇到
pop.ErrInvalidID，可统一转成c.Error(400, errors.New("invalid id format")) - 但注意：这个机制只对数字 ID 有效，对 slug、email、token 等字段无效，仍需手动校验
- 别依赖 ORM 报错当“正则约束”——它不提供明确的格式提示，调试时难定位是路由问题还是数据问题
真正容易被忽略的点
前端生成的链接如果带非法字符（比如 /users/abc），浏览器照发，Buffalo 路由照样匹配成功，只是 handler 里一解析就崩。你得确保错误响应是 400 而不是 500，否则监控系统会把大量格式错误当成服务异常。
