其实合肥软件这一块工资低选择少是事实，是比北上广深杭低很多。但问题在于，普遍来说，你在这几个大城市拿的是 10-30k 的薪资面对的却是两倍三倍于薪资的房价，合肥薪资虽然是 8-20k 但你面对的却是 1-2 万的房价。合肥 2 万能买很不错的位置的房子，但那五个一线城市 2 万 都买到农村去了……以后上班通勤都会限制你去不了啥好公司 否则就是每天起早摸黑太痛苦。综合来讲就收入支出比例来说，合肥还是稍微宜居一点的.不能总是太过于关注这个薪资值，也得看看和房价的比例。我也准备过两年会合肥了

16 寸 32G 一年的情况
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 20 Celsius
Available Spare: 100%
Available Spare Threshold: 99%
Percentage Used: 0%
Data Units Read: 15,058,133 [7.70 TB]
Data Units Written: 15,576,524 [7.97 TB]
Host Read Commands: 120,297,452
Host Write Commands: 172,008,071
Controller Busy Time: 0
Power Cycles: 100
Power On Hours: 128
Unsafe Shutdowns: 7
Media and Data Integrity Errors: 0
Error Information Log Entries: 0

@hairtion 有 我同事去 app store 买手机 当时她问花呗能不能分期 然后额度不够 店员就说可以并表示额度不是问题 然后当场操作 给她花呗加临时额度……

@hairtion 不仅可以分期 你要是分期额度不够 他们还会当场给你额度提额……

@tinybaby365 用 ccc 就不存在这问题 全量备份 300G 都很快 也就一二十分钟

很烦的 问题好多 我的 pad 离我挺远 每次我拿出耳机想连手机 总是被 pad 抢去 手机显示连接了 但是没用 非得我去拿 pad 在 pad 上面强制断开才行 烦的很

@mumbler 我一共就做过四次飞机，三次遇到气流，去新疆飞的时间还很长。那感觉就跟做拖拉机一样，一会上一会儿下的，不过就第一次紧张点，反正给我的感觉就是坐飞机太不舒服了，睡一会儿就被颠醒，晃来晃去，如果不是做火车太远啥的，我反正以后不做飞机，体验感太差。

经测试 是淘宝关键词触发那个需要注册 1000 天的

3. 先拿字节或者阿里练手，这俩会反复鞭尸的，适合练习
4. 去面想要去的公司

我来试试
1. 淘宝一套八股文视频，你 Java 的就搜 Java 的面试视频
2. 刷 Leetcode
3. 先拿 zj 或者 al 练手，这俩会反复鞭尸的，适合练习
4. 去面想要去的公司

@Rhonin 不好意思，你可能不知道什么是全局设计。也不懂啥叫泛型，不知道啥叫兼容。你直接说你懒得在前端做判断不就得了，还觉得不合理。不合理您倒是给出您的见解，并解决问题。而不是一句暴躁的不用辩了。您这么高贵，都不辩，那您在在个这个主题下发什么言，原来 v2 的某些前端就这个水平。另外你不认可的设计就说人大厂的就是屎山，我只能说您水平实在是高。拜拜了您嘞

@laminux29 1.不敢苟同您的加强鲁棒性设计。100 个字段出现 100 个状态字段再去分别表示状态，在我看来就是过度设计，滥用设计模式。完全是为了套设计模式而设计，增加了操作流程，延长了操作线。
2.不加状态字段，判断数据本身，如果发生错误，无非就是后端返回了前端没判断，后端没返回（如果前端判断了字段，即使后端出错，前端也不可能出错），那问题就回到了前端的判断问题。所以只需要前端看下代码有无判断就能立马知道是不是后端的错。再退一万步，您认为加了判断状态字段，排查快，不费时费力。但是您忽略了后端操作的错误性。如果上百个字段，您就能保证后端不犯错误忘记改某个字段状态？出现了问题，您能百分百确定是前端没判断 ，还是后端数据改变的不全？不还是得一个个去排查。而且还得是对着数据一个个看，看看哪个数据状态维护错了。您的加强鲁棒性吧问题前置到数据的初始化状态了，排查起来只会更复杂。本身并没有解决您说的犯错误问题。再退十万步，一个系统要想健壮就完全靠拼凑设计模式？就难道没有自测，测试专测，上线前回测，以及灰度？您所说的犯错误的情况在这些测试阶段就能被发现，解决您问题的是测试的流程而不是您的设计模式解决了犯错误的本质。
3.个人理解任何设计模式的流行必然有其合理性。但我认为合理的利用设计模式可以锦上添花，不合理的套用设计模式只会是增加复杂度，并不能实质性解决问题。

@Zoomz 你忘了可以配置 key 对应的值如果为 null，连 key 都不返回的吗……并不是非得是 map 装

@laminux29 加状态字段……然后一个接口 100 字段，外加 100 个状态字段，然后还得根据状态字段去决定是否渲染值…… 那为何不直接 if 字段 然后渲染…… 至于说的无法区分到底是 B 不存在还是前端忘了回发 B 的值，对于第二种，如果这个错误能犯，那你家状态字段，也可能会犯不判断状态的错误……这种问题就是自己的 bug 。对于第一种，只要你前端判断没有这个字段，至于后台是真有还是真没有，那是后端的事，出问题也是后端吧锅端着

@Rhonin 我不知道你有没有看别人网站接口的习惯，就我观察来看，很多大厂都是第一种情况，没有字段都不返回。就比如 msg data 两个参数来说，很多大厂都是如果接口返回错误信息 那就只返回 msg 字段 看不到 data 字段了，如果业务正常返回数据 那 msg 就没了 只有 data 。而且 data 通常都是动态的，有时候可能是单条数据 有时候可能是单字符 有时候可能是数组，按第二种方式来，如果 data 为空，没数据的时候，那这个 data 是给它赋值空字符 还是空数组？还是给它 null?其次有些字段用不到的返回有什么意义呢，显得 json 长吗？而且一般这种处理都是后端通用处理方式，不会是每个接口单独去处理到底该返回空字符还是 null 还是空数组问题，单个接口都来一遍，碰到字段多的，嵌套多的，得写多少个循环多少个 if……

@darknoll 嗯嗯 我是认为没有就不返回。返回的太全，容易被人猜到核心设计。很多产品能够存活就是设计的好。全字段返回，基本一个表的字段差不多都被猜个七七八八了，有了表结构和流程原样复制产品就太简单了。再一个就是你是没碰到那种上百字段的，如果没有信息的也展示，真的吧后端搞死……还存在嵌套的问题。而前端只需要一个 if 就可解决所有字段不存在的问题……而且本身前端也得校验数据，所以相比之下我觉得不返回字段更好

个人觉得没有就直接字段都不返回。理由是：首先没有也返回，前端返回大量字段为 null 或者为空字符，不觉得难看吗 其次有些人可能有某些字段 有些人没有某些字段 但因为是一张表 全字段返回，就容易让人猜到一些关键信息字段。最后就是 难道前端展示信息的时候 对于不是必然有的字段 进行展示的时候 都不 if 一下吗 就直接用？不管数据介凡辉结构啥样，我觉得对参数要判断下是基本操作吧，万一碰上个辣鸡后端骚操作，你不判断数据直接展示，哪天突然来个字段没了啥的，然后页面报错或者啥的，直接影响用户，严重的到时候背锅的可是自己。 所以我是认为没必要返回，前端对于不是必然出现的字段进行判断，保命要紧，不能把命运交在别人手上

@ruzztok 我两设备一个中区一个美区都是每天不同节点，也没被封，不太清楚你的啥情况。