先记住这个答案
安全方法（safe method）是指不会导致服务器状态改变的 HTTP 方法，本质上应是只读操作。GET 和 HEAD 被定义为安全方法，因为它们的语义是获取资源或资源元数据，不应对服务器产生副作用。即使服务器可能因日志记录而改变状态，但客户端调用时不应主动请求任何修改。
- 安全方法不请求改变服务器状态
- GET和HEAD是只读操作
- 安全不代表无任何服务端副作用
安全方法的定义机制
安全方法的核心是客户端发起的请求不应对服务器资源状态产生变化。例如，GET 请求应只读取资源表示，HEAD 则获取响应头而不含正文。这种语义保证了客户端可以安全地预取、爬取，而不必担心意外修改数据。
HTTP 规范要求服务器实现这些安全语义，但 Web 服务器本身（如 Apache、Nginx）无法强制，必须由应用逻辑保证。例如，一个 GET 请求若触发了订单创建，就违反了安全原则，属于实现错误。
链接预取的真实场景
假设一个文档网站希望浏览器预取下一篇文章的链接以提高加载速度。浏览器调用 GET /articles/next 来获取内容。因为 GET 是安全方法，客户端不请求改变服务器状态，因此服务器不应因该请求而修改业务数据或触发副作用。但服务器可以记录访问日志或保持统计信息；若预取请求被计入用户访问统计，会导致数据失真，因此应用应通过请求头等机制区分并排除预取请求。
处理上，服务器应确保该 GET 接口只返回资源，任何统计逻辑移至异步日志或单独上报。这样即使用户并未实际点击，也不会影响推荐算法或趋势数据。
安全方法的边界与失效条件
安全方法“安全”是语义层面的承诺，不保证物理上无副作用。例如服务器可以记录日志、更新缓存的命中数，这并不改变资源状态，但客户端不能要求这些操作。若服务器因 GET 请求而写入数据库或发送邮件，就破坏了安全语义。
失效场景常见于接口设计不佳，例如用 GET 调用删除操作（如 GET /delete?id=1）。这种实现不仅可能被爬虫触发，还会破坏链路预取。规范警告应用不应允许 GET 改变状态，开发者应审查所有 GET 端点，确保只读。
容易答错的地方
- 认为安全方法一定成功
- 安全仅指不改变状态，与响应状态码无关。GET 返回 404 或 500 仍是安全调用，因为它未引起副作用。成功失败看状态码，安全与否看是否修改资源。
- 认为 GET 请求永远无副作用
- 实现不当可能导致 GET 触发状态变化，但这违背语义。例如用 GET 执行支付操作，即使能工作也是错误设计，浏览器预取或爬虫访问会引发灾难。
面试官还会怎么问？
安全方法与幂等方法有什么关系？
所有安全方法都是幂等的，因为只读操作重复执行结果相同。但幂等方法不一定是安全的，如 PUT 和 DELETE 虽然幂等但会修改资源。
HEAD 与 GET 的响应有何不同？
HEAD 响应不包含消息体，仅返回头部；其头部字段应与 GET 完全相同（如果条件允许），便于客户端获取元数据而不传输内容。
OPTIONS 为什么也是安全方法？
OPTIONS 查询服务器支持的通信选项，如 Allow 头，不访问或修改资源，因此是安全的。但需注意其语义与 GET 不同。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。