SSH 私钥的密码，属于本地 pin ，不网络传输，且只能暴力破解。再目前的安全框架下，本地 pin ，哪怕就是 4 位数字，也是物理级别安全的。

1 ，不要把光猫当路由器用。
2 ，就是路由器的 DMZ 功能，也是个问题儿童类型的功能。

申请公网 IP 但是不桥接，你那个宽带师傅估计想砍你。

@nigga #48 如果这玩意，你们那边都已经墨守成规这样干了，那这样信用卡、贷款其实都没啥影响了，因为这俩看得实际是稳定流水，是不是明面工资无所谓，只要是实际工资就行。

但你这一毛不交就过分了，最少也要象征意义的交个几块。

基础设施云対标的是机房。机房的防火墙要在堡垒机或者网关上搞，国内云一般相应的也在虚拟内网——安全组上做防火墙配置。这就导致针对单个主机，或服务，的防火墙配置是画蛇添足的。当然也可以认为是懒。你这个的外部防火墙，大概率就在旁边的 “安全组” 那里做配置。

java.lang.Objects#equals Javadoc 的标题是：「 Indicates whether some other object is "equal to" this one.」 楼主脑回路不正常，理解成了「 Indicates whether some other object and this one is "the same one".」 然后接下来后面的人也照着这个思路去解释了。这真应了那句话：不要和白痴争辩，因为他会把你的智商拉到和他同一水平，然后用丰富的经验打败你。

长期用的的东西，不要看当前价格。

兄得，「 m1 pro 艾尔登法环 35 帧，只狼 40 帧，m1 赛博朋克 2077 Ultra 设置 15 帧」，知道这对真正的游戏玩家来说是啥概念吗，是「不能玩」。Mac 属于高端轻薄本系列，这系列的 Windows 原生系统，都是无法玩 dx12 游戏的，你就是 100%无性能损耗的模拟，也是屁用没有。第三方工具不适配 DX12 ，不是因为人家不能适配，而是适配了也毫无意义。

这里面的重点是：在帐务审计上，只有一张卡是工资，其他的卡即不算工资也不算劳务报酬。

如果你的打算是攒钱够了就跑，只要公司走好帐就百利无害（有人会来杠五险一金公司缴纳部分被坑了，不要听，那本质上也是税）。但如果你是打算长期稳定的工薪阶层的，那还是越早跑越好。因为你明面上的工资连起征点都不到，这在将来可能的离职补偿计算、信用卡申请、贷款申请上，甚至下一份工作的定薪上，都是严重的负面影响。

当你要看录取率的时候，不能单看高考录取率，还要看中考录取率。单看高考录取率，跟看平均数不看中位数是一样的效果。

华硕管家还勉强有点料，奥创就是个纯广告客户端。

注意重点：在外面等着。这根寄存男友之后独自逛街，区别不大，毕竟薛之谦张杰不算小鲜肉。

200 以下的便宜机械键盘出问题很正常，惠普、戴尔这俩擅长压缩成本的大厂更容易出这种隐藏小问题。这个价位的键盘是给你入门试轴用的。

手机能访问，电脑 refused ，这八成电脑上的防火墙干的。

你这 3965u 是 「英特尔® 赛扬® 处理器 3965U 」吗，如果是的话，别找原因了，硬件不行。

你的网络拓扑里面，AX6000 路由器退化成交换机了，软路由承担了全部的路由器功能。这套功能里面，IP 层、数据链路层的一些功能，计算量可不小，软路由只能做软件层面的软处理，对 CPU 是性能要求是远大于专用驱动应处理的常规路由器的。

改一下网络拓扑应该就解决了。把路由器换回原本该有的位置，然后改默认网关，把 3965u 变成旁路由。

源代码无知识产权，只能通过保密来保护，但审核是要提交源代码的，所以在苹果那里源代码压根就不存在任何法律保护。只要你不先申请专利（国内还额外有个没啥实际卵用的软件著作权），提交上去就算送给苹果了。苹果要造一个同质的，连静室开发都不用搞，现搬代码都没法律负担。

Mysql InnoDB 引擎下，有两个特殊性：一，主键索引是聚集索引，主键索引就是最终数据存储；二，基于一，其他索引指向的目的地是主键，而非通常的隐藏 rownum 。

对于特殊性一，因为主键索引就是全部数据，而你只用主键做排序条件，主键索引又是 btree 的天然具有顺序性，所以就无需做排序了，直接在主键索引上筛选数据就够了。这就是你 explain 只看到 using where 的原因。

对于特殊性二，a 字段的 btree 索引上，索引值就是 b 字段的值，故全部查询内容都在这个索引上，可以直接在这个索引上做查询和排序，也不用回落数据文件。当然这个并没有被采用，因为用特殊性一的处理会更快。

@makelove #8 掣肘不是监管。PWA 需要操作系统 + 浏览器双重支撑。如果不要平台支撑功能，那就不是跟 WEB 应用同质化了，那是扩裤子放屁的分身。

@lsk569937453 #4
@realpg #17 #22
@tabris17 #18

不管是分布式事务，还是等消息处理成功才正式生成订单，这是 CP without A 的分布式原则选择，强一致但是低可用。下订单的场景明显不能采用这种原则。

经典的异步乱序难题。你这个还好解决一些。

我这里假定「苹果+1 」、「苹果-1 」是两个事件，如果你用得不是事件驱动而是常规 REST 接口，那么可以把事件看作接口的入参对象，把事件消费过程看作接口的方法体。

首先，开了异步，并且还有严重级别的一致性问题，那么相关操作都要当作业务数据去存储。对于你的案例，就是「苹果+1 」、「苹果-1 」这些事件的消费记录，要当作业务数据存到数据库中。

「苹果-1 」事件无依赖，它的消费过程不用动。

「苹果+1 」事件必须晚于「苹果-1 」事件被消费，故它在消费时，要先去查找一下对应的「苹果-1 」事件是否有消费记录。如果没有，则停止当前消费过程，并追加延迟消费逻辑。延迟消费逻辑，可以简单的记消费失败并让发布事件那一方短暂延迟后重新发布事件（对于 REST 接口来说，就是接口抛异常，调用方捕获到异常之后，sleep ，然后重新调接口），也可以记消费成功但同时发布新的「苹果+1 延迟」事件（这个如果是 REST 接口，就有点难弄了，你需要额外加延迟调度框架，绝对不能在 REST 接口中 sleep ）。

如果条件允许的话，还是用 Kafka 做事件驱动的基础设施，它能保证顺序消费。