没看懂，
正文说：“客户端传入 start_date=2020-05-01，end_date=2020-05-20 时，这条记录需要被查出来”
二楼说：“我传 start_date=2020-05-10，end_date=2020-05-20 这时候是不应该搜出这条记录的”
所以是需要查出来还是不需要查出来？

跑 Docker 之前好像有问题，不知道解决了没有

张小龙：我 tmd 也没想到你们拿他来办公啊

完美的不太可能，但是如果你可选范围不大的话，可以大概猜一下，比如内容是否符合 utf-8 的变长编码方式，是否落在 GBK 编码范围：8140 － FEFE，剔除 xx7F 码位之类的。
很久以前我还做过就是比如抽取一段出来用一种编码去读入，看看有没有报错，没报错就转 utf8 再转回来比较一下和之前是不是一致的之类的各种土法炼钢。

两份收入肯定是两份税，但是那些专项附加扣除的，对同一专项附加扣除项目，在一个纳税年度内只能选择从一处取得的所得中减除。然后就是税率，因为每一个公司都只能各自按照累计预扣法预扣预缴个人所得税，所以第二年做前一年的汇算的时候，有可能两个地方收入加起来涉及到更高级别的税率，那样预交的就不够了，可能就要补税。
不过在我看来，既然是你的公司，这点增加的税比公司其它税低多了

现在不行了，早期确实可以的，我的家庭组就是两个美区一个中国区，不过前一段要加我爸也已经加不进去了

我估计因为即使是阿婆内部的本地化的测试人员，看到周日开始的日历也没有觉得什么不对，因为日常在国内生活中看到的日历也是这样的。所以确实也说不上什么错。
至于 GB/T，本身就是个推荐标准，各人可以根据自己的情况决定是否采用。

如果是你举得这个例子，也就是说包含进来的信息本身就不用收到未来修改的影响的话，我觉得是没问题的。比如订单信息，很多时候本来就最好保留一个订单商品信息的当前快照，及时以后修改了商品的信息也不应该修改这个订单的信息。
但是其它情况，如果包含进来的信息是可能会需要随着未来的变动而修改的话，比如用户有好友信息，好友改了昵称后用户的好友列表也需要对应修改，这时候就要考虑什么时候同步这个修改了。

之前不懂的概念现在懂了这种情况很正常，尤其是自学的人。好比有的事情看第一本书时还是有点蒙，换一本接着看有时就有豁然开朗的感觉。但是这并不代表后者就一定是比前者好，很多时候是前者搭了 80%的基础，后者正好从某个适合自己的方向推了一把让你解锁了某方面成就而已。两手都要抓，两手都要硬，二者是相辅相成不可分割………………（对不起，走错片场了）

产品经理的完整的带交互的原型就是一个项目初期最完整的功能示意了吧。所以这个需要代替产品经理之外的所有角色。

Mesh 最佳，再次电力猫也差不多了。

北京联通，平时 1000 下 40 上，疫情期间上传 120 （到 2 月 29 日下午 4 点）

@yanyueio 我大概记得以前类似这么用拦截器干过，在 preHandle 里去取对应方法的 RequiredPermission 注解，如果有有就判断里面提供的权限。没有再配置 SpringSercurity 了。不过那些都是些小项目，基本上权限管理，登陆验证，token 生成存储与验证之类的都是土法炼钢一整套

试了一下没问题啊： https://www.codeweavers.com/store

4.8G 是单核睿频，这个指标感觉基本没什么用，日常确实不可能出现。全核的话，你这 i9-9880H 正常是到 4.1G ，更高一档那个 i9-9980HK 也不过到 4.2

按 12306 的设定同方向时间冲突的票是没法出的吧