Controller方法参数需按顺序声明：路由参数（如int $id）→服务→Request对象；$request->get()自动处理表单，JSON需手动解析；配置参数用getParameter()且键名用下划线。
Controller 方法参数怎么写才不报错？
Symfony 会自动把匹配的路由参数、Request 对象、服务等“塞进”控制器方法里，但顺序和类型必须严格匹配——错一个，就抛 ParameterNotFoundException 或 LogicException。
常见错误现象：访问 /user/123 却提示 “Controller method argument "$id" has no value”，或干脆 500 报错说无法解析参数。
- 动态路由参数（如
{id}）必须作为**普通 PHP 参数**声明，类型可省略（public function show($id)），但推荐加类型（public function show(int $id)），这样能触发自动转换+校验 -
Request对象必须用完整命名空间：Symfony\Component\HttpFoundation\Request，且**必须放在所有简单类型参数之后**（比如不能写成function show(Request $request, int $id)） - 服务注入（如
EntityManagerInterface）可以穿插在中间，但 Symfony 会按类型优先匹配；避免混用同类型多个服务（比如两个LoggerInterface实例）
GET/POST 数据到底该用哪个方法取？
别依赖 $request->query->get() 或 $request->request->get() 硬编码判断——HTTP 方法变了，你得跟着改。直接用 $request->get() 更稳，它会自动从 query 或 request body 里找同名参数（前提是 content-type 是 application/x-www-form-urlencoded 或 multipart/form-data）。
但注意：JSON 请求体不会被 $request->get() 自动解析，必须手动 $request->getContent() + json_decode()。
- 表单提交（
POST /form）→ 用$request->get('username')最简 - API JSON 请求（
Content-Type: application/json）→ 先$content = $request->getContent()，再$data = json_decode($content, true)，然后取$data['email'] - 想统一处理？加个请求体解析中间件，或用
RequestBodyParamConverter（需启用 SensioFrameworkExtraBundle）
怎么安全读取 YAML 配置里的自定义参数？
别用 $this->get('nacho_image.upload') 这种老写法——它在 Symfony 4+ 已废弃，会直接报错 ServiceNotFoundException。正确姿势是调用容器的 getParameter() 方法，且 key 必须和 config/services.yaml 或 config/packages/*.yaml 里定义的完全一致。
典型坑：配置里写的是 nacho_image: { upload: true }，结果代码里写 $this->getParameter('nacho.image.upload')（用了点号）——实际要写成 $this->getParameter('nacho_image.upload')（下划线）。
- 配置项路径 = YAML 中的层级 + 下划线拼接，不是点号嵌套
- 确保参数已加载：检查
config/services.yaml是否有parameters:块，或是否通过imports:引入了含parameters:的文件 - 类型安全起见，建议在 controller 构造函数里注入参数（用
#[Autowire]或构造器参数类型提示），而不是运行时查容器
为什么路由参数有时是字符串，有时又自动转成 int？
因为 Symfony 默认把所有路由参数当字符串处理。哪怕 URL 是 /post/123，$id 传进来也是 '123' 字符串——如果你在方法签名里写了 int $id，Symfony 会尝试 cast，但失败时抛 RuntimeException（比如值是 'abc'）。
真正可控的转换靠路由约束（requirements），不是 PHP 类型声明。
- 加正则限制：在路由中写
requirements: { id: '\d+' }，这样非法值（如/post/abc）根本不会进 controller，直接 404 - 加类型提示只是辅助验证，不是转换开关；没加
requirements时，int $id只会在 runtime 强转，容易崩 - 复合参数（如
{slug}-{id}）必须用requirements明确切分逻辑，否则全当字符串传进来，后续拆解易出错
最常被忽略的一点：开发环境关掉 debug 模式后，路由匹配失败不会显示详细错误，而是静默 404——这时候你以为参数没传进去，其实是路由根本没匹配上。
