RequestMapping默认是get还是post？答案是：都不默认。它默认匹配所有HTTP方法。

这个误区的来源很直接。很多初学者写第一个Spring MVC接口时，只写了@RequestMapping("/hello")，然后用浏览器地址栏直接访问，能通。浏览器发的是GET请求，于是他们记住了“默认是GET”。但真相是——浏览器只能发GET，你根本没测过POST。

拿代码说话。Spring源码里RequestMappingInfo的创建逻辑，如果没显式指定method属性，那么methods条件就是空集合。空集合意味着“不限制方法”。GET能进，POST能进，PUT、DELETE、PATCH都能进。哪怕你发个OPTIONS，它也会匹配上——只要路径对得上。

我见过一个真实事故。某团队内部管理系统，有个删除数据的接口写成@RequestMapping("/deleteUser")，没指定method。他们内部调用全走POST，相安无事。结果某天外部爬虫用GET请求扫到这个路径，直接触发删除逻辑。好在删的是测试数据，不然就是生产事故。这不是段子，是2019年某电商公司的真实案例。

所以当你写下@RequestMapping时，等于把你的接口大门敞开，所有方法都能进。这在RESTful风格里是个安全隐患。GET请求会被浏览器预加载、被代理服务器缓存、被爬虫顺手抓取，而你的接口可能做了修改数据的操作。

那怎么区分？Spring提供了衍生注解：@GetMapping、@PostMapping、@PutMapping、@DeleteMapping、@PatchMapping。这些才是明确限定单一方法的。用它们，代码可读性高，安全边界清晰。我几乎不用裸的@RequestMapping，除非是类级别的路径前缀——那种情况配合方法级别的具体注解，是标准玩法。

再深挖一层。如果你确实写了@RequestMapping(value="/x", method=RequestMethod.GET)，那它和@GetMapping("/x")完全等价。但注意，Spring 4.3之后才引入这些组合注解，老项目里还是能看到一堆裸RequestMapping。它们能跑，但属于技术债。

还有个冷门细节。如果类上和方法上都加了RequestMapping，且都没指定method，那么类级别的路径和方法级别的路径会拼接，但方法限制条件还是空的。也就是说，整个控制器下所有接口都接受任意HTTP方法。这比你想的还要宽松。

实际开发建议：新代码一律用组合注解。如果遇到历史遗留的裸RequestMapping，要么补上method属性，要么改成具体注解。别偷懒，这跟你锁门是一个道理——你家的门不会默认只让走左边的人进，对吧？

最后补一刀。测试时别只测GET。用Postman或curl发个POST看看，八成能通。通了别惊讶，这是设计如此，不是bug。但如果你写的是支付回调接口，那建议立刻加上方法限制，否则迟早有人拿GET调你的回调，白嫖你的业务逻辑。