举报没问题啊，一般是走劳动仲裁，有时间可以去仲裁处咨询一下或者电话咨询：举报 996 需要提供什么证据。留心保存一下证据，然后再花点时间往返几次只有工作时间上班的仲裁处。方式方法正确，结局往往都比较理想。互联网也并没有那么严格的背调，不用担心再找工作问题。而且从性价比和风险的层面来看，被举报的厂子几乎不可能后续找你茬。

@iowt #62 好不好用发个帖兄弟。
另外我从来不擦屏幕啥的，没想到还有这么多门道。
要是这个抛光布对普通屏幕也有用，而且大兄弟你用过之后还不错，那我就直接一步到位得了。

@lightjiao #53 这，三点我全都反对。。。
- 服务端即便使用相同的语言重写，改动也一定是巨大的，巨大到等同于完全重写。
- 客户端换了引擎在延用架构和工作流？我也用过不少引擎，没发现有哪两个引擎可以共用甚至是一小部分工作流的。代码照抄是更不可能的，客户端的改动比服务端的改动只大不小。如果如楼上所说更换了同步方案，那前端的核心系统几乎是 100%重写。
- 手游因为资源量的限制，美术资源应该都是重做过的，甚至为了适应移动平台格式都有做优化和调整，内部应该有工具可以做一部分批量操作，减少一部分工作量。

去过一次，玩的啥没印象，但是对吃是真的印象深刻。就去过的好多国内城市来说，算一流梯队。有太阳有云的天气，配合海边城市特有的干净整洁，真的让人心旷神怡。
关于海鲜，我去的那次是租了民宿，去市场买的海鲜和朋友一起下锅烹制的，想去的朋友如果有水煮海鲜的能力，完全可以优先考虑订民宿。
另外我们还特地去吃了一顿野馄饨，不知道算不算当地特色？小串烧烤配馄饨，挺香的，还想吃。

看到上面一堆理中客好来气啊，脏话估计发不出去我先这里自我屏蔽 20 字以上的脏话。

拿快递最零散的淘宝来举例，从快递类型上来说，有包邮的产品，也有需要额外付邮费的产品，也会有本来包邮但是我希望有更好的快递服务从而加价要求顺丰的情况。从成本上来讲每一种情况我都付了快递费。
既然我付了快递费，什么情况下我没权利要求快递上门？什么叫我付的钱不够？商品本身也没有让我选择“快递到快递点”和“快递上门”服务啊？既然没这个选择，那依据法律法规，凭什么我不能默认理解快递应该是送上门的？还特么有说让我塞 20 块钱给快递员的？
理中客怎么不说这钱不是我不愿意给，而是快递公司的压榨，平台没有提供功能，商家自己承担了成本的问题？非要在这儿圣母说不是快递员的问题吗？

关于塞钱不塞钱的问题，拿京东和淘宝的对比举例，绝大部分情况下，京东的商品比淘宝是要贵的，我特么愿意多付钱给京东不就是说明我愿意塞钱来换取更好的服务。咋的在座的谁还没在京东上买过东西吗？所以这“因为你舍不得塞钱”的狗屁理论是哪来的逻辑？

快递员被压榨，当然是个问题，但是这个问题真的需要所有的客户都秉持圣母心态，忍气吞声当做无事发生吗？为什么不应该是，由于客户没有收到快递公司压榨，所以更有意愿发声，从而有“可能”倒逼快递行业调整呢？比如被媒体声讨多次的外卖员群体，难道是因为外卖群体在发声吗？他们身处群体内部，恰恰不敢发声，反而应该是多亏了客户群体的声讨，从而触发了媒体感知，再然后倒逼外卖公司调整的吧？

用过几次 react-query，见过 swr 很多次但是没有使用过。
刚刚去仔细看了一下 swr 的文档，看起来在用法上比 react-query 稍微轻巧一些，比如 react-query 的 {enable} 选项，在 swr 实现的很自然。

但是不知道是不是我的问题，感觉 swr 的中文文档不太好理解，比如：
“条件数据请求”里解释 key 不变会导致即使 token 变化也会返回脏数据，这一部分的解释看的我挺懵的，继续往下看并且结合曾在 react-query 中看到过的解释才理解，原来是因为 hook 的第一个参数整体被当做一个 key，来处理了缓存相关的功能，所以 fetcher 里面的逻辑在 key 不变的情况下可能根本不会被触发。
另外对于“传入参数”这部分文档，我感觉最顶上的“等价”部分反而会导致理解混淆：当我看到等价的时候，下意识的觉得“既然等价那就都可以咯？”，但是其实这部分文档更重要的是说明 hook 第一个参数的整体性。即当你需要可变参数时，不要在 fetcher 方法里直接引用，而是使用 hook 的第一个参数，利用数组进行传参，从而实现当数组数据变化时，引发 key （ swr 概念中的） 变化，进而触发 swr 进行重新计算和验证。这个概念其实就是主流框架本身的概念，还是挺好理解的。但是因为没有解释，不容易触发联想。而且还有最上面的文档来混淆。。。

我个人感觉的话，其实 react-query 的文档也比较让人头大，因为他虽然每个概念解释的很细，但是不太具有关联性，需要自己在使用中串联起来。swr 的文档则是不够细，主体以小例子为主，少见介绍背后的原理或者原因，所以理解起来比较困难。

@qinxi #24 回来了，因为意外去祁连，被 G213 颠吐了。

手机上比这更过分
https://tva1.sinaimg.cn/large/008i3skNly1gu3kahap96j60x40mmwfm02.jpg

@qinxi #21 那可能是车的个体差异，反正印象巨差。carplay 啥的，国产车现在配置都很高，可是驾乘体验就很难说。

下周正好去大环线，小环线上有哪些推荐和不推荐吗？参考一下。

@eastlhu #18 这么大区别的吗？半个月前才租的宝沃 7，油门前重后轻，启停稍微一点就窜，刹车刚好相反，不踩到底等于没踩。如果你的车也是这种状况只是你比较适应的话，我建议就别 ”yyds“ 了。。。

理念和实现都很棒，感觉也有一些潜力，但是对 extend 里的 Vue 风格实在是喜欢不起来。。。

一些建议：
1. TypeScript 支持，仅我个人而言，没有 TS 支持的库项目我都不会尝试；
2. attribute 里的 type 能不能换成 enum，用原生类型感觉会限制当前的实现，比如可以内置实现 ref：Car{ brand, color }, User{ car: Ref(Car) }。可能也限制了用户可能需要的动态扩展能力，比如自行扩展成 UUID，BigNumber 等；
3. 实例方法里的 this 看的我很慌，如果想写成箭头方法咋整？
4. 实例方法里，能不能做到只需要 return data，不用手写 this.attributes = data ？
5. User 提供一个构造参数应该灵活一点: const user = new User({name, age})，实例里没提供这种用法，提供一个 object 的写法不容易漏属性；
6. this.attributes = data 的具体作用是啥？如果把 save 实现在静态方法里：save(user) {}，看起来也是可以的，这样是不是就既可以使用箭头方法，又不需要写 this.attributes = data ？

资源都能上 cdn 了，那 html 文件的“工程化”是要做什么？为了什么目的？

用 mac 的朋友们，如果不考虑 safari 的前提下，如果 chrome 的整体使用流畅度是 10 的话，edge 大概在 8-9，ff 只能打到 7， 上面有人提到的 vivaldi 我只能给 5 分。
edge 的评分是基于部分功能特性有的人需要有的人无所谓，比如我觉得扩展的支持度还是不够好，但是有的人觉得无所谓这种，整体是没啥大问题的，但是最近如楼主所说的阴间“特性”变多，感觉很难受；
ff 是真的不够流畅，跟任何设置都无关，tab 多了以后，滚动、hover 等交互有明显的掉帧或者延迟；
vivaldi 看到不少人推荐，windows 下怎么样不知道，mac 是连看 youtube 都疯狂掉帧的，其他地方的性能比 ff 还差一大截，tab 功能是一大卖点，但是设置项又太少（具体需要的设置忘了），简单来说是个半成品，完全不推荐主力使用；

这个能让我这种不会玩德扑的进阶吗？

@kekeabab #1 你这角度有问题，虽然结果钱确实没变少，但是过程是不合理的。
首先你要绑卡到美团里，其次你要申请从余额里退款到银行卡里，然后再通过银行卡转账还款。最后你还要记得解绑美团里的银行卡。
本来并不需要用户做什么，而且美团是完全有能力原路退回的，其他所有带支付的平台都可以做到。

人在首都，刚下地铁，大雨没带伞，小米手机快没电。
我简单说两句：
不好意思我走错片场了。