zgray

同样的问题，另一个帖子说抹盘重装一两天了貌似暂时稳。我刚抹盘完，在恢复数据中。

@Liuzeyu 同样期待你的反馈，我也等着看看是不是要抹盘重装。

@Sazazel 我也有类似的问题，19 款 16 寸定制刚到货一段时间。期待你的反馈。目前该问题似乎无解，也是烦人。。。

photo sync 配合一个文件存储服务器，我是这么干的。

感觉应该是插头把 mbp 的 type-c 的雷电口捅坏了，楼主仔细看看是不是雷电口问题，这个的话去天才吧也只是帮你矫正下，应该是免费。以前我 mbp 2015 款也有一次把雷电口里面的一个金属片弄坏了，然后死机（可能短路了）

可能你需要升级下工具了，有个和 V2EX 的工具名字很像的你值得拥有。

我认为 http 的状态码表示的往往是 http 请求的状态情况，比如 301、302、403、404、500 等等，指的是服务器状态，非业务状态。
我目前对 http 状态码是这样思考的：
1. 对于所有的业务请求，首先如果能响应，则返回 200 码应该是认为请求成功（可能业务出错）
2. 然后在保证了正确响应(200)的情况下，对于业务错误和正确响应是否要统一格式输出的话这个我认为这个是不同团队的处理模式的习惯问题。

我先说下统一格式为{code: xx, msg: xx, data: xx} 这种的：
一般这种的格式，在 API 调用方很清晰，拿到 HTTP 请求的响应后二话不说直接转为一个统一个 ApiResult 结构，然后判断 code，如果非 0，拿 msg 进行提示。这个思路对于大多数前端很直白。

对于另一种情况，成功业务返回 data，异常业务返回 errorCode 的：
那么规则就成了先把结果转 JSON，然后判断是否存在 errorCode 属性，存在认为有错那 msg 提示，否则正常业务。

上述两种模式的第二种存在很明显的问题，就是：要求 data 区域返回值不能有 errorCode。因此对于这种模式一般要区分状态码，比如非 200 表示业务报错，然后辅助判断。我认为楼主说的是这种模式。

这里我觉得两个都行，只是第一个模式思路对大多数人来说很直白而已。第二种模式的话如果 API 调用方的开发环境可控问题也不大。但是！！！


对，我这里要说一个但是！！！微信下开发，那坑爹的安卓版微信浏览器，会默认采用代理发请求，当服务端返回非 200 的响应码时，微信代理抛弃请求，一样的请求从客户端直连二次请求发起！！！
一个案例就是：用户注册，输入用户名服务器判断是否重复注册，此时 ajax 返回非 200 错误比如(500)，然后 response 是错误信息，服务器会二次收到重复的用户注册请求！！！这个坑我相信做个微信开发的人大多数都遇到过。

也是这个坑踩完我重新思考了下状态码的问题，于是就有了第一种方案的结论。

在用 13 的人告诉你，尽可能上高配不后悔。

如果没有长期骑行的经验，建议先在休息日的时候先做一些适应性锻炼，然后再自行评估。运动这个事，每个人的体制不同，有的人骑车 1 小时没事人，有的人骑 30 分钟累半死。