request::getmethod() 是判断 symfony2 请求方式最直接可靠的方式，返回大写字符串如"get"或"post"，应结合 getpathinfo() 确认资源位置，而非依赖 server 变量、参数存在性或路由路径。
Request::getMethod() 是判断 Symfony2 请求方式最直接、最可靠的方式，不是靠解析 $_SERVER['REQUEST_METHOD'] 或检查参数存在与否。
怎么用 Request::getMethod() 判断 GET/POST
在 Controller 的 Action 方法里，从 $request 对象取方法名字符串，注意它返回的是大写字符串（如 "GET" 或 "POST"），不是布尔值：
$method = $request->getMethod(); // 返回 string
if ($method === 'GET') {
// 处理 GET 逻辑
}
if ($method === 'POST') {
// 处理 POST 逻辑
}
- 别用
$request->isMethod('post')—— 这个方法在 Symfony 2.8+ 已废弃，2.x 后期版本会触发 E_USER_DEPRECATED - 别依赖
$request->query->has('xxx')或$request->request->has('xxx')反推请求类型：GET 请求也可能带request参数（比如表单 enctype="multipart/form-data" + GET 提交），POST 也可能没传任何 body 数据 - 如果用了表单 CSRF 保护，
POST请求必须包含_token字段，但这属于业务校验层，不能替代 HTTP 方法判断
为什么不能只看路径或路由匹配来归类请求
同一个路径（比如 /user/profile）完全可能被不同 HTTP 方法复用，Symfony 路由默认不区分 method，除非显式配置：
profile_edit:
path: /user/profile
methods: [GET, POST] # 必须手动加 methods 限制，否则 GET/POST 都能命中
defaults: { _controller: AppBundle:User:profile }
- 没加
methods时，profile_edit路由对所有方法开放，仅靠路径无法归类 - 即使路径不同（如
/user/profile/editvs/user/profile/update），也可能是人为约定，不是协议层面保证；真实请求仍可能用 GET 访问 update 路径（比如调试时 curl 手动发） - 前端 JS 发起的
fetch('/user/profile', {method: 'POST'})和表单<form method="post"></form>在服务端看到的都是POST，路径一样但语义不同——这时 method 才是唯一可信依据
获取访问路径的三个关键属性区别
$request->getPathInfo()、$request->getRequestUri()、$request->getBaseUrl() 容易混淆，实际用途差异明显：
-
$request->getPathInfo()：返回路由系统解析后的路径（去掉 base URL 和 query string），比如访问http://localhost/app_dev.php/user/list?sort=name→ 返回/user/list，这是做路由匹配和权限判断时该用的值 -
$request->getRequestUri()：返回原始 URI（含 query string），如/app_dev.php/user/list?sort=name，适合日志记录或透传给第三方服务 -
$request->getBaseUrl()：返回入口脚本路径，如/app_dev.php或/web/app.php，一般不用直接读，框架内部用得多 - 别用
$_SERVER['REQUEST_URI']替代$request->getRequestUri()：前者未经过 Symfony 的编码清理，可能含非法字符或双斜杠，后者已 normalize 过
真正要归类请求，核心就两条：先用 $request->getMethod() 确认动词，再用 $request->getPathInfo() 确认资源位置。其他字段（如 header、content-type）只是辅助，不能替代这两个基础判断。
