Safari 表示秒开

这个标题简直是日经问题。。。

1，人家售后也有售后的流程，模块化的产品基本都是只能换不能修。
2，你保修期已经过了，人家不可能免费帮你拆机检测。拆机有有风险的，保内拆机出问题，厂家承担。保外帮你拆机拆坏了谁承担？
3，保修期已经过了还去售后修那就是交智商税。随便找个修理店，几十分钟就能知道到底是哪里出问题，再决定修不修。不修也就几十块钱的拆机费。

@no1xsyzy 问的意思就是“先发请求确定用户名是否存在，再进行注册”，这个请求你用什么状态码来表示用户已存在，并且决定后续走流程 A 还是流程 B 。我们说的不够清楚吗？

说了这么多您还没有个准确的回答，其实我心里已经有答案了。

“你难道没有发现这种情况下任何人可以通过你放出的界面来知晓任何一名用户的常用地？”，你凭什么可以知晓任何用户的常用地？你只能得到当前 ip 不是常用地，想知道常用地，必须准确的模拟出该用户的常用 ip 甚至常用设备来请求，才能得到是真实 IP 的结果。

回到标题“为什么后端开发都喜欢自己定义 responseCode ？ HTTP 状态码不够用吗？”，答案就是 http 状态码根本无法代替业务状态码来使用，http 状态码真的不够用，除非你的业务够简单。

不再回复了。

@no1xsyzy 那我再详细描述一下，在可以自定义用户名的注册场景下，用户输入用户名，需要检测用户名是否存在，如果存在，则根据用户常用登录地提供两种逻辑，在常用地，提示找回密码或者直接登录。不在常用地，推荐一组可用用户名。请问如何用 http 状态码表示用户名已存在。

如果你觉得实现不了就是设计失误，那我只能说这是常见场景。

@no1xsyzy 我已经确定了，是你没看懂。。已经说的很明白了，是在注册的时候，去检测用户名是否存在。不去后端检测，如何能确定用户名是否已存在呢？检测用户名是否存在这个请求不应该发？

@no1xsyzy 不是，还是我描述的不清楚吗？用户名存在之后你是通过什么决定前端去请求推荐用户名 api 呢？就通过接口是 404 吗？那我换一种说法。。比如常用登录地匹配上的话可能要提示用户是否需要直接登录或者找回密码，没有匹配上则要给出推荐用户名，这种如何实现呢？
还有全站 https 和 404 没有什么关系啊，我的意思是只要能影响你 dns 的，都有可能给到 404 的结果。api 服务升级，导致 path 变化也可能导致老版本客户端 404 的。或者域名发生变化也有可能 404 。这么多情况下，客户端如何记录日志呢。

@no1xsyzy 抱歉我的描述不清楚，让你误解了。。我其实想了解一下#128 楼这种需求如何解决？就是注册时用户名已存在，同时后端给出推荐用户名。

官网购买即可避免

@no1xsyzy #132 是认真的吗？你这样不还得判断字符串吗？ 404 不只是后端会给你，路由器、运营商、设备都有可能给你，不做判断了吗？

M 记不好吃，而且拉肚子。。。原来不是我一个人

@liuxu 你这个第 4 条 not in 性能堪忧啊。。。既然都用上内存缓存了，直接把 userid 存内存不好吗。

@awen233333 咱这乡下不太一样吧，您南方的？北方农村哪有什么大排档奶茶，连个餐馆都没有，村里最多有几个小卖部，也没山没水。同龄年轻人在家的很少，也没法约朋友。这谁能受得了。