@faqqcn #25 这其实是好的，本质上对敏感信息脱敏了，服务商不会拿着你的密码去其他地方撞库。以目前的计算机能力来看，32 位已经足够对抗暴力破解了。

有些朋友说 cookie = 密码，多数情况下，这是对的，不过这任然取决于服务提供商的策略以及他们认为应该提供多大的安全校验。

比如国内的很多银行 cookie 与登入的 IP 是绑定的，变更 IP 后，原先的登录状态会失效。

原则上找经销商售后是可以的。这符合三包规定，京东比较好的一点是硬刚能刚下来的。

可以参考消费者权益保护法
第 23 条：消费者自接受商品或者服务之日起六个月内发现瑕疵，发生争议的，由经营者承担有关瑕疵的举证责任。（举证责任倒置）
第 24 条：七日后符合法定解除合同条件的，消费者可以及时退货，不符合法定解除合同条件的，可以要求经营者履行更换、修理等义务。
第 48 条第八款 /第 56 条第八款：对消费者提出的修理、重作、更换、退货、补足商品数量、退还货款和服务费用或者赔偿损失的要求，故意拖延或者无理拒绝的；

结合第 24 、48 条，原则上是可以要求退货的。

只不过比较折腾一点，但也不会花费太多时间。如果真的想硬刚建议直接上司法程序，行政流程我走过 3 、4 个月才有结果，司法程序通常不需要等到结果，庭前就可以解决掉，所以速度还可以的话，一个月就可以搞定

外置存储权限的问题，可以统一拒绝，目前手持 K20 Pro，Android 11，所有应用都拒绝了外置存储，一切正常。

缺点：
1 、微信、QQ 不能直接发图片，需要从相册分享发送。
2 、12123 不能使用，它在启动的时候非要在外置存储写个文件，所以我现在不用了，网页版也可以用，只不过没那么方便而已，交管业务一般也不会很频繁的使用。

目前大厂应用（腾讯、阿里、美团、头条系） Target API 都已经在 29 或以上了，API 26 以下的应用已经非常少了。

同工不同酬，同人不同命。

这种事情很难说的，每个人对自己的定位也不一定都准确。

我也面试过一些人，自称会前端，但实际水平可能是 jQuery 那一套，webpack 没听过，我也不能说 jQuery 不是前端，但现在用的地方真的少了。

还有一些人自称是会 Java 后端，只会 spring boot 一把唆（就这还有些唆不动，大概就是知道 @RequestMapping 这样的几个注解，其他全家桶里的都没用过）

找工作嘛，本身就是一场博弈，看谁的议价能力强，当然大多数情况下是用人单位有更大的议价能力。

@duanxianze #68 这还真不是，大多数对系统的修改的能力上限，就在改壁纸了。习惯才是最大的壁垒。如果习惯这么容易改变，也不会有那么多人无法跳出舒适区了。

首先排除一个错误答案，四季青（多数商家并不做零售）

手持红米 K20 PRO，Android 11，是可以拒绝所有应用的外部存储权限的，我这装了 100 多个大大小小的应用都可以正常使用。

不嫌麻烦，微信、QQ 也可以通过相册分享发送图片，可以保持不给权限的发图。

超市门口 10 块钱快剪，我去过好几个超市门口的，都还行，并不比四五十的 Tony 老师差，上来也不罗嗦，唯一的缺点是要回家洗头。

@NPC666
@calmzhu 请教两位大佬，vuetifyjs 中的虚拟滚动条非常好，对于巨长信息流的展示可以有效提高性能，但是由于我原本的布局是采用 v-row+v-col 响应式依据页面宽度换行的，而把这一套放到 v-virtual-scroll 里面以后，则每行只能一个 v-col，这对我来说非常苦恼，搜了一下（ https://github.com/vuetifyjs/vuetify/issues/11756 ）似乎开发者并不对这个感兴趣。

那么有啥变通的方法能够同时使用 vuetify 的布局系统，同时也可以使用它的虚拟滚动条呢？

感谢大佬~

别管是不是形式，只要有了，领导就不背锅，大不了是一线人员执行不到位或者是被检查人员弄虚作假，怎么都不会是领导负直接责任。
在这种大是大非面前，该有的形式还是要有的。

大公司相对好很多，取车前着重检查车辆外观，划痕等，和工作人员确认是取车时就存在的，避免还车时被认为是你造成的剐蹭。
如果对自己驾驶技术没有信心，不计免赔可以考虑。这样验车环节也不重要了，非重特大事故，基本都和你没关系。

如果不熟悉，取车时请咨询工作人员，油箱盖、灯光、雨刮等如何操作，避免尴尬（通常是德系车操作略有不同，开车少的话，可能一下子找不到。）

我也是后端自学的。
有开发经验的前提下，vue 门槛算是很低的了，配合 vuetify 一类的组件，可以很低成本的快速做出一个还看得过去的网页。
在配合 webpack 的情况下，也具有一定的工程性，自学还是推荐 vue，真的简单。

@cz5424 #9 倒也不是内存泄漏，因为这个工具主要的作用是一个胶水工具，把几个第三方工具整合到一起，因此用一些 WIN32 API 把不同第三方工具弄到一个界面里（ SetParent ），这其中又涉及到由于网络原因，某些第三方工具可能会打开失败，那么其他已经打开的应用就需要统一一起关闭，这里面处理太麻烦了。经常会造成整合的界面显示奇奇怪怪以及焦点获取有问题

很久没做 Windows 桌面应用开发了，最近写了一个（还用了一些 WIN32 API ），但是重复使用下，重置应用状态太麻烦了，改了半天总会出些奇奇怪怪的问题。

实在没办法了，每次用户点新的请求都自己重启应用，还是这样省事。

各位大佬有没有遇到一些（ c/cxx ）开源项目使用 WSL2 编译会有一些奇奇怪怪的错误？最后我又专门开个虚拟机去编译。

@ryd994 #20 这个其实和具体业务有关，如果通讯量比较大的情况下，其实 SSL 还是很费 CPU 的。握手的开销更多是网络 IO 慢。当然啦，如果调用量不大，可以无脑上 SSL，绝大多数情况下，机器性能是过剩的。

我以前做过一个中间件，内网调用也走的 HTTPS （调用频率比较高全天基本稳定在一个数值，没有低谷期），业务服务器 CPU 大量都被 nginx 占用了，后面找运维大哥说明一下情况，内网不再使用 HTTPS 后（同时为确保安全，只接受固定 IP 的请求），机器负载明显降低了。