确实，Chrome处理204响应的这个逻辑在测试接口时真的挺闹心的——刚输完接口地址发送请求，地址栏直接跳回之前的页面URL，哪怕之前的URL本身无效或者也返回204，反复输入地址太影响效率了。这里有几个实用的解决办法：

• 用开发者工具的Network面板测试（最推荐）
  打开Chrome开发者工具（快捷键F12或Ctrl+Shift+I），切换到Network标签页，先勾选顶部的Preserve log选项（防止请求日志被刷新）。之后直接在地址栏输入接口URL访问，或者通过Console发送请求，Chrome就不会修改地址栏了，你还能在Network面板里清晰查看响应状态、请求头、响应头等信息，甚至可以右键请求选择Copy as cURL来进一步调试。

• 临时修改后端响应状态码
  如果你有权限修改后端接口代码，可以临时把204响应改成200，同时返回一个空的响应体或者简单的提示文本（比如{"status":"success"}）。Chrome收到200响应后就不会替换地址栏，测试完成后再改回204即可。这个方法适合需要直接在地址栏访问接口的场景。

• 通过Console发送请求
  直接在开发者工具的Console标签页里用JS代码发送请求，比如：

  // 示例：GET请求
  fetch('https://your-api-endpoint.com/test', { method: 'GET' })
    .then(response => console.log('响应状态码:', response.status))
    .catch(error => console.error('请求出错:', error));
  

  这种方式完全不会影响地址栏，还能实时在Console里看到请求结果，测试单个接口非常方便。

顺便提一句，Chrome的这个行为其实是符合HTTP 204响应的规范（204表示请求成功但无内容，浏览器不应更新当前文档视图），但在测试场景下确实不够友好，上面的方法应该能帮你解决这个问题。

备注：内容来源于stack exchange，提问作者Luke