超市门口 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 的请求），机器负载明显降低了。

A 反代 B，如果 A 与 B 之间的链路是可以信任的（如完全可控的内网环境），就可以不走 SSL，以降低 CPU 使用率。
如果 A 与 B 之间的链路不可信，那么 SSL 还是不建议省略掉，以避免由于 A->B 请求中可能出现的中间人，造成客户端请求 A 时的结果也不可信

你原来 12k 月薪按 955 算，时薪是 68.97 元
而新的 25k 按 996 算（你说的上班时间 12 小时？），时薪是 80.9 元（月平均工作日取 25.75 天）

这其实算起来只是给了你加班费，平时加班按法律规定 1.5 倍，看起来工资多了，更多的是依靠延长工作时间获得，而不是依靠提升单位时间的价值获得。

开源的意义在于如果原作者不愿意，我们可以自己动手，如果你愿意可以把代码 PR 回去，如果不愿意，也可以自己维护一个版本。

因此原作者不愿意添加某些功能影响也不大呀，如果自己不能、不会、不愿意添加自己想要的功能，这时候也许要考虑付费了。

9900K 编译一次应该不需要这么久，即使是全量编译也不需要，检查一下是否磁盘存在瓶颈。我用 8700 全量编译也就 1 个小时，之后增量编译就 3 分钟以内（如果跳过 CTS 检查可以到 1 分钟以内）

我有一台工作电脑，非常的神奇，有一块 AMD 亮机卡和 i7 10700，同时外接了三个显示器。

只要使用 Chromium 内核的浏览器在外接显卡的显示器上打开腾讯视频就蓝屏，显示内存分页错误。

这应该是 7 层干的事情，网络层去搞，非常麻烦，要不你统一在目标应用上加前置代理，由前置代理决定出口，如果目标应用不提供使用代理的功能，就套上 proxychains，这相对来说容易实现，成本也低。

而你要分析 HTTP 头，那注定不能是 HTTPS，除非客户端信任你的自签证书，也就是说本身你的应用场景应该就是可控的场景，而不是针对任意第三方，所以加代理可能是比较容易的。

因为 markdown 在有渲染的情况下，表达能力比纯文本丰富，在没有渲染的情况下，由于标记简单，肉眼也可以看出格式，几乎不影响阅读。比如想编译某个项目，git clone 以后，cat ./README.md ，即使没有富文本渲染，也可以阅读。而在 GitHub 网页上，渲染后阅读效果更好。

而 HTML 不渲染，人眼是没法看的。