喷了一个没写过接口的后台服务器开发人员的后果

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2864 天前的主题，其中的信息可能已经有所发展或是发生改变。

刚去一个公司，喷了一个没写过接口的后台开发人员，结果搞的自己也很 Lower 。喷的原因很简单，接口地址写错，参数写错，拖延整个项目进度，压缩自己的开发时间，随意更改字段名。现在决心不说话，避免被说成是心态不好，大惊小怪。好无语。求安慰。

重要的不是能力，而是和谐的团队氛围，你认同这句话吗？

第 1 条附言 · 2017-01-23 16:20:16 +08:00

统一回复各位：第一次玩 V2Ex,没想到这么多人浏览和回复。感谢大家！

总结下：

1.的确是我这个心态不好,即使有什么问题，即使因为对方的问题拖延了整个项目,压缩了自己的项目开发时间,甚至导致整体的延期与加班,也应该委婉的去表达自己的意思。另外项目是公司的,拖延了自然会有上面的人去找原因,我刚去又只是个小兵,更何况在试用期(虽然我不在意找工作这件事)，但如果控制不了自己的脾气是成不了事情的。

---无论你工作多久,去一家新公司,你就是个新人,毋庸置疑。少说话多做事。

2.我只是喷(而非骂,指出具体错误的地方和建议,当然可能语气会有不好的地方。),但是稍微大点的公司都会有些办公室政治(大家都懂的)，对方即使有什么问题，最好能够私下沟通，不要放到明面上。把别人变 lower 的同时自己也会很 lower 。何必给自己和他人添堵呢?

--- 闷声发大财,做好自己的工作,但工作不是全部,要想自己生活的开心,最重要也最基本的,不给自己添堵。

3.进入社会 7 年有余,因为自己的火爆脾气吃了不少亏,但是行走江湖,脾气不好,又想吃好或者没有其他手艺只能吃这碗饭,要么是仗剑倚势不怕得罪人，要么就改掉自己的脾气做个老实人。千万不要落个无才无德最无用的结局，所以摆正好自己的心态,把工作做好,默默的提升自己.把日子踏踏实实的过好了而且越来越好才是最最重要的。

--- 连自己都控制不了的人,怎么去领导别人? 怎么让自己一步步的走向成功呢？

4.无意间见到几个现实中熟识的朋友在这里,就不在这继续发着无用的牢骚，撒播负能量了。

最后：写了很多废话,请各位见谅.感谢一路走来遇见的人。无论是好人还是坏人,技术好的还是技术差的,男的还是女的.感谢让自己成长的人,祝愿各位 2017 新年快乐！

字段名

接口

后台

开发

109 条回复 • 2017-01-31 06:30:07 +08:00

1 2

❮

❯

2017-01-22 21:40:18 +08:00 via iPhone

有问题不能好好说，一定要喷？以为跟混论坛一样呢

nicevar

2017-01-22 21:44:31 +08:00

同事一上来就喷？平时网上喷习惯了吧，先沟通一下再喷也不迟

hiboshi

2017-01-22 22:04:37 +08:00

能控制住自己情绪的人能成大事。

HLT

2017-01-22 22:07:53 +08:00

刚去就喷人，之后有你受的。。。

hexzhou

2017-01-22 22:08:32 +08:00 via iPhone

楼主你有点专家心态了，你也知道别人没写过，一上来就开喷。

jmc891205

2017-01-22 22:22:22 +08:00

你可以邮件写明情况指出他的错误并抄送通知他 manager
直接骂人就显得不太会混职场了

liangWL

2017-01-22 22:31:00 +08:00

楼主。我认同你说的最后一句话，但是，喷人就不好了，你可以向上面反映，直接扣工资，就 ok,他会记住你的，而且肯定会改正的，短时间之内会恨你，等他想明白了，就会感激你的，其实默默做个好人也行，我不介意别人认为我有多坏，自己问心无愧就好。

lalalanet

2017-01-22 23:08:12 +08:00

重要的是你换个靠谱的公司，打工找个同事平均水平比自己高的公司上班去

imlewc

2017-01-22 23:13:14 +08:00

改东西？
有原因么？
好的原因要接受
不要一开始就喷
这样对自己身体不好
要是傻逼顺便改的
....

立下规矩

lcdtyph

2017-01-22 23:18:51 +08:00

楼主说的“喷”显然不是骂了那个人的意思吧……

Immortal

2017-01-23 00:05:41 +08:00

就是流程太乱。。。
我写服务端也就写了 1 年 api 之前一直在做 web
两边都有问题吧

ihuotui

2017-01-23 00:13:33 +08:00

改变能改变，不能改变就接受或者换一个地方。

noli

2017-01-23 00:26:38 +08:00

这有什么，我今天喷了一个 Android 兼职过来写 php 后台不懂什么叫 Http Status Code 的家伙。
能用 400 Bad Request 解决问题非要返回一个字符串或者 json 的。
反正又不是我发工资，我喷他为毛呢。

当然，我的重点其实是想说 php 是最好的语言。

ETiV

2017-01-23 00:37:33 +08:00 via iPhone

长者教导我们闷声发大财，所以我从来都是看在眼里，记在心上。

yxzblue

2017-01-23 01:02:06 +08:00

这也来求安慰！心真大

srx1982

2017-01-23 01:06:42 +08:00

地址，参数，字段名，如果有接口文档的话不会写错吧？如果文档详尽易懂再写错就是诚信了吧？前提是详尽易懂哦

yangqi

2017-01-23 01:23:43 +08:00

就是心态问题，不说话更是心态问题。谁不是从没有经验过来的？有什么问题好好说不行？

yangqi

2017-01-23 01:24:43 +08:00

另外，能力很重要，但是团队的和谐比能力更加的重要

Phariel

2017-01-23 02:14:46 +08:00 via Android

楼主啊你要记住喷人者恒被喷之你是典型的一时爽

janstk

2017-01-23 07:25:44 +08:00 via Android

哟哟。楼主我认得你。 m 神啊😂😂

des

2017-01-23 08:47:25 +08:00 via Android

@noli 如果是业务逻辑出错，用 JSON 不是挺好的吗？不过用字符串就纯属坑人了。
等会。。。 400 Bad Request ，你确定不是你自己的锅吗？？

knight322

2017-01-23 08:55:06 +08:00

@des
hahah 何必说穿呢

waczx

2017-01-23 08:58:34 +08:00

@des
hahah 何必说穿呢

des

2017-01-23 09:00:54 +08:00 via Android

@knight322
@waczx
为啥你俩回复一毛一样？

waczx

2017-01-23 09:01:34 +08:00

@des
我故意的，--）

des

2017-01-23 09:06:59 +08:00 via Android

@waczx 我以为是在玩那种，“整个论坛都是我的小号，信不信我换个号回复你”

yidinghe

2017-01-23 09:07:13 +08:00 via Android

纯粹的喷，对方是听不进去的，你最终也只是发泄而已。当我要表达不满的时候，首先会考虑对方是否已经和我一样意识到问题存在，如果是，那我就跳过喷的阶段，直接给些有用的意见。

csx163

2017-01-23 09:08:47 +08:00

@noli 我觉得报错误代码不太好吧

FanError

2017-01-23 09:11:43 +08:00

@noli v2 有个流派就是统一返回 json ，通过里面自定义的 code 来区分错误。

FanError

2017-01-23 09:12:27 +08:00

@noli 我也是属于这种流派，哈哈

yoke123

2017-01-23 09:13:19 +08:00

大兄弟都是打工的何必呢都退一步你好我好大家好+_+

TonyYOYO

2017-01-23 09:30:46 +08:00 via iPhone

最可怕我给服务端指出问题，人家就是不改…一个借楼搞定的事儿，非得俩

laoyur

2017-01-23 09:36:31 +08:00

@noli 你觉得直接用 http 400 好，人家也有 http 200 + json 的理

des

2017-01-23 09:40:52 +08:00 via Android

@laoyur
重点难道不是 “ 400 Bad Request ”吗？
为什么你们关注点都那么奇怪啊？

mengzhuo

2017-01-23 09:44:40 +08:00

╮(╯▽╰)╭
RESTFUL 用 status code 是标准啊，但不上 https 没有意义，客户端能力跟不上也没有意义。
所以最后一般都会妥协成返回 json ，内含错误码。

laoyur

2017-01-23 09:48:14 +08:00

@des 没 get 到你的槽点

smithtel

2017-01-23 09:48:16 +08:00

@des 状态码报文没啥问题，一直丢 400 就是客户端错误，这锅就丢的好了，反正不是我的锅。

smithtel

2017-01-23 09:50:04 +08:00

@laoyur @mengzhuo 没 get 到槽点,400 是前端请求问题，不是后台锅。

laoyur

2017-01-23 09:55:16 +08:00

@smithtel “ 400 是前端请求问题，不是后台锅”——这可不一定

jtam

2017-01-23 09:56:07 +08:00

很 Lower ……

killerv

2017-01-23 10:07:03 +08:00

@noli 并不是非得严格按照 http 状态码返回， 200 的 http code 加上 json 没问题

mazyi

2017-01-23 10:36:42 +08:00

接口定义好了就不准备，变了就骂，

pengfei

2017-01-23 10:44:59 +08:00

有接口设计文档呀

shenhongbang

2017-01-23 10:46:39 +08:00

想解决问题呢就好好说话好好沟通，想单纯的干架就是一上来就喷喽

noli

2017-01-23 11:03:49 +08:00

@laoyur @des @FanError @csx163 几位没在大公司干过吧？

noli

2017-01-23 11:05:51 +08:00

@laoyur @des @FanError @csx163 抱歉，手快没回复完就发出去了
赶紧把锅丢出去才是正道。
反正 RESTFul 规范在那里，你要另外发明一个协议麻烦你仔细写出来。

holy_sin

2017-01-23 11:24:55 +08:00

你咋没削他呢

yura93

2017-01-23 11:34:40 +08:00

接口地址和参数和 Json 例子不是应该测试完毕 API 后放到内部开发平台上给前面人用吗?也不是需求变,自己频繁更改,可能没经验

kanezeng

2017-01-23 11:59:17 +08:00

@noli 大家说得没错啊， RESTFul 不是协议，也不是规范，只不过是诸多 WEB API 设计架构中被比较多人说得比较多的一种而已。
没人规定说 WEB API 一定要按 REST 来设计，事实上能看到的很多 API 要么并不按 REST 来做，要么并没有严格按照 REST 来做。

总结一下，上面说的那么些，我想表达的是 REST 只不过是一种架构，做 WEB API 时不需要一定要跟着他，同样大家在这里讨论 WEB API 的时候，也不需要拿他来说什么。

那么说回用 HTTP 状态码，还是单独返回一个状态码？这个我估计 V2 上可能都争论过很多次，支持的双方都有吧。
从我个人来说，我更喜欢单独返回一个状态码，用来把业务逻辑的状态，和非业务逻辑的状态区分开来。

再总结一下，后面说得这么些，我想表达的这两种做法没有绝对的对错，没有必要因为别人和自己的选择不同而喷对方。这个选择应该是公司来做，如果公司没做好，喷的是公司。

noli

2017-01-23 12:03:00 +08:00

@kanezeng 针对一个具体项目来说，选择 RESTful 规范就是一个省力的做法。

mikulch

2017-01-23 12:11:34 +08:00

感觉国内的人工作的怨气很大，性格很焦躁啊。
是不是觉得你喷了别人了所以显得自己特别牛逼？
当工作合作上出现问题的时候，自己是否想过，做过下面这些？

1. 对方这样写的理由是什么，是否因为某些需求不好解决或者临时性的需求变更，所以才这么做的？
2. 和对方沟通，告诉他你的临时解决方案，对我造成了很大的困扰。所以我们应该一起拿出一个更好的解决方案。
3. 不要觉得大家都是傻逼，自己是聪明人。职场上做的好人往往是你们看不起的傻子，而不是经常显摆自己很聪明的那种人。
4. 谦虚是一种很可贵的品德。项目是团队做出来的，不是一个人搞出来的。

break

2017-01-23 12:26:52 +08:00 via iPhone

别人没写过，有啥好喷的，你行你上啊。带带人家呗

assassinpig

2017-01-23 13:43:38 +08:00

有的就是重视说出来, 之后就没事了，谁能不错，错了还不能说才是问题
有的就是不能直接说粗来，怕伤了和气, 彼此以后不好再见面

baoguok

2017-01-23 13:54:09 +08:00

项目去求、接口定义，这些前期确定了，后面就按照文档开发，怎么会有频繁更改的问题。

很显然是公司没有流程，和写没写过接口无关

mhycy

2017-01-23 14:45:09 +08:00

@noli 不止应用层会抛 HTTP 状态码，依据不同的环境架构，有时候直接 200 使用 json 格式返回状态码会是更优的做法。

learnshare

2017-01-23 14:51:10 +08:00

老司机带带他，何必歧视小学生

just4test

2017-01-23 15:07:04 +08:00

我一般是对方同一个错误犯第三次开喷。

@mhycy “有时候直接 200 使用 json 格式返回状态码会是更优的做法。” 这点我一直不太明白用 body 返回状态码的优势所在。可以说明吗？

zhoubug

2017-01-23 15:18:23 +08:00

做些无啥含量的 REST 交互无论前后台有啥资格互喷的。。。

jucelin

2017-01-23 15:41:23 +08:00

@just4test https://www.v2ex.com/t/191534 这个应该是他（@mhycy ）说的一种情况

tyo

2017-01-23 15:41:52 +08:00

@janstk 哈哈哈

ihuotui

2017-01-23 15:54:03 +08:00

如果用 HTTP 状态码，就是把协议变为两个，一个 HTTP 状态码一个 json ，复杂度增加。
然后用 HTTP 状态码越具体，越不能拓展，就像泛型一下才好拓展，越抽象越好拓展。

tairan2006

2017-01-23 16:24:39 +08:00

换公司，下一题

sobigfish

2017-01-23 16:42:33 +08:00

接口地址写错，参数写错，拖延整个项目进度，压缩自己的开发时间，随意更改字段名....
话说 API 没文档？这个锅应该 pm 背吧

simo

2017-01-23 18:04:30 +08:00

唉，和和气气，坐办公室油子，谁都会， but ，真不容易做到。

simo

2017-01-23 18:10:10 +08:00

@mikulch 道理通，说的很对。
多次出现以下的类似情况，你（角色只是一个前端或者后端开发人员）会如何做？（真心求解）
例：你是前端开发，编辑用户接口，后端接口返回项里有 “密码” 这一项

noli

2017-01-23 18:50:05 +08:00 via iPhone

@mhycy 但是 4XX 错误肯定不是环境的问题啊，更进一步，如果不是协议上的问题而是例如连接问题，你扔个 200 过去也不能保证客户端能正确接收

jarlyyn

2017-01-23 19:04:31 +08:00

慢着，楼上那些讨论 api 的。

为什么 4xx 错误会和 json 的状态码有关系？

4xx 错误不是对应的是 200 么？

就算 4xx 错误，典型如 422,也要返回具体的错误数据啊？

跑 2xx,3xx,4xx,5xx 只是为了让缓存服务器和客户端更好的处理啊。

mhycy

2017-01-23 19:21:27 +08:00

@noli 要考虑到网络上各种奇葩的中间设备会有的奇葩规则，开发时还是要看 API 用在哪个地方
如果是内网，不经过啥奇葩的中间设备的话， HTTP 状态码直接表示资源状态也是可以的。
但是在外网，考虑到各种奇葩的中间设备有可能存在的情况下， 200 是个更稳妥的选择。

dantangfan

2017-01-23 19:29:49 +08:00

一个吐槽贴，被强行转成了状态吗的月经贴。

noli

2017-01-23 19:36:25 +08:00 via iPhone

@mhycy 考虑的设备更多应用涉及的规模越大才更应该好好地使用 Http 状态码，毕竟 http 状态码是 RFC 上定义的而你自己定义的状态码只是你的什么鬼文档里定义的。试图在一个庞大系统中的单点解决所有问题，这是想得太多，优化太早。

hcymk2

2017-01-23 19:39:03 +08:00

大厂的.
https://developers.google.com/drive/v3/web/handle-errors

hcymk2

2017-01-23 19:41:00 +08:00

另一个大厂的
http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html

mhycy

2017-01-23 20:25:56 +08:00

@noli
考虑到项目的规模才应该使用更通用的实现，即便这个实现在某些时候看上去并不“优雅”
为了“优雅”而对问题视而不见，这不是一个合格的工程师应有的态度

noli

2017-01-23 21:55:36 +08:00

@mhycy 你说的原则我很同意。但我觉得 Http Status 比 Json 或者别的什么格式表示的 status 更“通用”，更简单更暴力更少歧义。任何一个合格 Http Client 都肯定能解析得出这个 http status 。

mhycy

2017-01-23 22:00:12 +08:00

@noli
当你遇上一个没法更改的机房设备的时候你就不会这么说了。。
HTTP 状态码来表示资源状态那当然是很好的做法
但是当网络路径中存在一些奇葩的设备带有奇葩规则的时候这就不是一个合适的选择了

这也是我在上文中强调“外网”的原因。

jingniao

2017-01-23 22:22:09 +08:00

手上的项目其实挺想用成 rest ful 标准的的状态码的。
但没用，前端没配合，可能在他们眼里，这是给他们增加工作量

noli

2017-01-23 22:22:25 +08:00

@mhycy 你说的不就是明文 HTTP 被中间设备篡改内容而已嘛。担心这个，上 HTTPS 才是正途，而不是在 API 上面搞什么自主创新，开发者的时间重新发明轮子来处理这个问题根本就是浪费时间。

mhycy

2017-01-23 22:53:53 +08:00

@noli HTTPS 也可以劫持，别忽略例外情况

noli

2017-01-23 23:10:36 +08:00

@mhycy 我知道在使用劣质 CA 签发的证书的情况下 HTTPS 可以等于没有，但排除这种情况之后， HTTPS 是无法劫持的。即使是存在劣质 CA 这样情况，因为存在 HTTPS 劫持的缘故多花时间重新做一套本来解决 HTTP Status code 就足以解决的问题，依然是不值得的。并且，如果连 HTTPS 劫持都做得出来，你觉得我们讨论在 JSON 里面放 400 还是用 HTTP Status 来放 400 什么的，这些还有意义吗？

mhycy

2017-01-23 23:30:27 +08:00

@noli
其实我想说的情况是公司内部自签发证书在网关拦截请求进行监控的情况下 HTTPS 是不可靠的。

考虑到运维以及可能出现的各种网络问题引起的状态码异常（客户端劫持）
我是认为 Web 环境中不适宜用 HTTP 状态码来代表业务状态，软件的 API 倒是可以用这种形式来实现。
但是为了明确区分应用层故障还是网络异常， HTTP 状态码保持 200 在某些时候是更合适的选择。

noli

2017-01-24 01:17:23 +08:00

@mhycy 你说的情况通常都是针对浏览器、 web 内容为主的应用，这种情况会需要担心网关和证书。但对于 Restful API Client 来说，你可以指定要信任的少数证书，那么 HTTPS 是不可能被劫持的。在这种前提下，我们才可以无后顾之忧地讨论 API 设计。从这个基础开始出发，我来举例为什么总是保持 200 是不好的： HTTP 协议本身就已经工作在应用层，就是一个应用层协议，但是 HTTP 本身也有会话（ Session ）的概念，总是保持 200 会强迫不同协议层面（例如会话层）必须深入理解应用层协议才能决定如何处理会话。比如， HTTP 4XX 5XX 这种是一种很常见的足以让中间节点判断是否可以中断会话的信号，以及请求幂等性和结果缓存等等等优化。通通都用 200 来表示，莫非是打算叫 CDN 服务商帮忙写代码么。

sueslee

2017-01-24 01:31:35 +08:00

lower 是啥

hcymk2

2017-01-24 01:34:54 +08:00

@noli
别说那么多 ,去看下那些大厂是什么做的.
别太教条了.
你要先考虑下你的接口能不能被别人调用到再说. 你是没有碰到到有些只处理成功(200)的人

noli

2017-01-24 01:47:52 +08:00

@hcymk2 你贴的 Google 和 Amazon 的例子难道不就是 Http Status Code + Json 的好例子么？你从哪里看到他们告诉你返回的都是 200 ？

hcymk2

2017-01-24 02:14:16 +08:00

@noli
Google drive 例子 body 里面的 code 是什么?
s3 drive 例子 body 的 code 是什么?
不能只靠 HTTP response status codes
而且 google drive 是 HTTP error codes and messages in the header

noli

2017-01-24 02:35:53 +08:00 via iPhone

@hcymk2 对啊，所以只要被 Api 处理到了就返回 200 ，这不是大厂推荐的做法啊，保持返回 200 就是我反对的，你有什么意见吗？

mhycy

2017-01-24 03:01:51 +08:00

@noli
理性点看待问题，话不要说绝。
在 Web 场景下保持 200+JSON 响应消息这么设计是很合理的选择。
不要为了反对而反对，除非你能给出更优解。

套用知乎句式 “抛开场景谈设计就是耍流氓”

changwei

2017-01-24 03:49:15 +08:00 via Android

这个公司既然都是招这种水平的人，说明楼主入职之前对公司调研不够啊。

Symo

2017-01-24 10:11:46 +08:00

@noli 你对, 你有理, 你赢了.
开心吗, 满足了你的自尊心和虚荣心了嘛.

noli

2017-01-24 10:36:44 +08:00 via iPhone

@mhycy web 场景下我也没觉得 200+json 有什么特别的优势。当然啦，受制于国内的实际情况--很多 web 前端只是半桶水，不喜欢上 https 甚至 https 据说也被劫持--用 200+json 的好处也就就是能适应这种状况了，但非要说这是优势的话，我想起了这笑话: 中国人最大的特质是什么？贫穷。

noli

2017-01-24 10:39:11 +08:00 via iPhone

@Symo 觉得不屑与我讨论就请拉黑加屏蔽，众目睽睽之下拉坨屎你这是干嘛呢？好了，现在屎拉到我身上了，满足了你奇葩的虚荣心了吗？

chairuosen

2017-01-24 11:18:59 +08:00

@noli 如果你只用 HTTP STATUS CODE ，如果业务错误类型多于 HTTP STATUS 类型，而前端又想区分出错误类型，怎么办。

noli

2017-01-24 11:52:23 +08:00 via iPhone

@chairuosen 我没有说过只用 http status code 。我是反对，无论 api 如何处理请求都返回 200 。

chairuosen

2017-01-24 12:04:34 +08:00

@noli 那就相当于有两个 code 字段了。 http status code 只是 json 中 code 的子集，所以前端肯定只用 json 中的 code ， http status 变成了冗余字段

noli

2017-01-24 12:08:42 +08:00 via iPhone

@chairuosen 只有不懂 rfc 威力的人才敢说 http status code 是冗余字段，理由我说了，全是 200 的话，你就别指望中间节点替你做进一步优化。再简单一点的例子，一堆客户端上为你做请求监控和警报的库也废掉了

chairuosen

2017-01-24 12:14:44 +08:00

@noli 这一点确实没考虑到

mhycy

2017-01-24 13:26:05 +08:00

@noli
我觉得已经没必要讨论下去了。
你这么说法完全就是为了反对而反对了。

noli

2017-01-24 13:35:53 +08:00

@mhycy 主要是你得出使用 200 + json 的结论依据，在我这里看来是说不通的：
你认为：中间设备干扰 and HTTPS 也可能被劫持 and 非 200 HTTP 回复可能会被劫持，这是我从讨论中知道的你使用 200 + json 的理由。
我认为：如果 HTTPS 都劫持，那么使用 200 + json 的做法，在大规模网络应用，是缺点多于优点。

我觉得确实没什么好讨论的，明摆着大厂都不用你的做法。
而如果你的业务够小，你喜欢怎么来当然都是 OK 的 --- 那不如更直接一点，直接在 80 端口上走自定义协议不是更好么，反正你也不需要 HTTP 的特别加持。

mhycy

2017-01-24 13:38:51 +08:00

@noli 请教缺点多于优点的缺点是啥

100

noli

2017-01-24 13:53:44 +08:00

@mhycy 总结 200 + json 对比较大规模 API 服务的缺点：
1. 对于会话层不友好：具体来说就是，譬如上面讨论说到的缓存控制， API 警报监控之类的应用，光这一点我觉得已经足够了。
2. 对于开发者不友好：如果使用你的 API 不仅仅是 web 端，还包括移动端甚至别的端，那么你就要保证这些端都要有解析 json 或者 xml 或者别的什么格式的能力，才能知道如何处理你的消息；这也意味着对更多的开发者来说，除了 HTTP 以外他们必须关注你的自定义格式，但是假如我仅仅是写一个小 demo ，我不关心出错信息，只想尽快跑通， json
+ 200 的做法，就给这种快速开发测试的需求制造了不必要的障碍。

事实上，如果你真的很关心浏览器使用 API 时受到的干扰，那么你完全可以用 open resty 之类的或者别的流水线，自己写一个简单的报文解析，根据 Agent 和回复报文内容，将 Agent 是浏览器的 HTTP 回复的 status 统一改成 200

1 2

❮

❯