已经腱鞘炎了，那就只能选垂直鼠标、轨迹球了。都有缺点，垂直鼠标影响精准度，轨迹球需要更换使用习惯且非常废拇指。

垂直鼠标就是把拿鼠标的姿势，从手掌向下，变成垂直方向的手掌向里。没啥高科技，就是进口的也是便宜货，直接搜索垂直鼠标，就能看到图。

轨迹球鼠标，就是把以前的滚轮鼠标，反过来用。滚轮鼠标是移动鼠标本身触发滚轮的转动，轨迹球鼠标是鼠标本身不动，用拇指去转动滚轮。这玩意其实也没啥高科技，不过就是太小众，所以出得少。罗技出过一款，后来连升级开发都懒得搞。

你特娘的在搞笑，AWS 又不是没有 x86 服务器。

不用大厂，国内软件开发，只要风头出得高的，都是「齐达内+帕文」模式，「齐达内」走了立刻就凉。不过呢，这里的「齐达内」，是基本不可能技术层面的，自然也基本不会是那些所谓的「大佬」。

机械搬运这种明显能定量的任务，出现计划任务量跟实际完成量差距悬殊的情况，先放着这个不说。真实生活场景，去依赖 gpt ，就不是成年人该干的事。

成年人的世界：
首先就不会干带实习生这种背锅侠角色的工作；
其次就不会管实习生在干什么，只会管他能完成多少任务；
再次，对待实习生只有两个态度，没关系的，能教就教不能教就晾着等他实习期结束自行离开，有关系的，当成爹伺候；
最后回到最开始的地方，计划任务量是跟着实际任务量走的，计划多次不完成，你要有权力就按着人加班让实际量赶上去，没权力就降低计划量——这种明明没法完成，还压着计划量不变的领导，只会越来越压不住人

先想想 Session 是什么，微服务之间能不能有 Session 。

我又给看了一下，目前发现的 NAT 打洞方式，是在没有或者不利用 UPnP 、DMZ 、PCP 等静态端口转发设置的情况下，利用第三方服务器做一个类似于 BT tracker 的作用，借助于 NAT 原本的自动端口转发规则，将两个端连接起来。

NAT 打洞，不需要路由器开启 UPnP 、DMZ 、PCP 等服务，但是，需要路由器的 NAT 协议，仍然是每个级别的路由器都得是，宽松的。这玩意没啥额外性能要求，因为本来就用得是原生 NAT ，就看运营商想不想给了。

@amyw495062 #14 运营商还真有开端口转发的试验 /t/603512 ，你看看你们那里有没有这个服务。

NAT 打洞，其实已经不是正常的 NAT 协议了，都用了一些黑科技，这玩意运营商可能就不知道，所以不用找运营商，找了也没用。

@amyw495062 #8 需要的是所有级别 NAT 路由器都开相关服务，运营商那里的内网路由器不开，你这边不管光猫还是路由器，开了都是白搭。而运营商那里，压根不可能给开。这不光是想不想的问题，运营商内网端最低也是 16 位掩码，一个内网段动辄上万台终端，压根就开不了任何端口转发。

改了有啥用，重点不是几级 NAT ，重点是 NAT 路由器那里能不能开 UPnP 、DMZ 等端口映射服务。

云服务不容易挂，你这个单点的「替代人工的自动化程序」，那可是非常容易出 bug ，非常频繁的因为水土不服而失效。

@Conantv2 #10
@Conantv2 #15

不要急，注册公司只不过没油水，没人想去管，还没来得及更新而已。这其实就是一个滥用信用造成的信用力下降问题。以前身份证只有特殊场景用，就算加上出借身份证的场景，也没达到滥用的地步，所以身份证具有很高的信用效力，光给给身份证就足够了。现在是一个保安、一个鸡毛蒜皮的小应用都能要求强制给出各种个人信息，别说身份证跟废纸一样，就是人脸识别的信用力都没有了。

@Mitt #23
@Bad0Guy #30
我说牛粪臭，你们来句马粪也臭，这是承认牛粪臭了吧。

@xixun #5 欧洲支持，就等于「当地法律法规」都得支持

楼上一个个那么急着给 Apple 甩锅的，大概是生活在，「 iOS 应用不用 Apple 审核就能装，iOS 应用销售不用被强制抽走 30% 给 Apple 上供」的平行世界吧。

你这个是很经典的默认打开方式问题，这玩意要管理起来不是一般的复杂，参见 Windows 上乱成一锅粥的默认打开方式。

但更主要的，还是不想把控制权交给用户，参见微软，都被强制要求小组件的链接用默认浏览器而不是 Edge 打开，还是只给欧洲用户搞。罪魁祸首是操作系统，一点问题都没有。

作为一个干了超长时间的后端，给点经验之谈。

一、压根没必要去深究前端做还是后端做，因为绝大多数情况下，两边都可以做。如果不是两边都可以做，那么前后端就还不是两个端。

二、对于旧项目来说，优先遵循既往习惯。如果以前就是前端做，那就继续前端做，哪怕这次后端改着更省事。反之亦然。如果你不这么做，那么将来改 BUG 的时候铁定要吃苦头。

三、对于全新项目来说，以工作量平衡为目标，让前端、后端、总架构、项目经理先去协商，协商好了之后，继续优先遵循既往习惯。

一堆人用，不一定是好用，而往往是没得选。如果你不用 mybatis ，那么剩下的只有两条路：Hibernate ，但是门槛高，不适合国情；啥也不用直接用 JDBC + 手写 SQL ，项目规模稍微超过 「 Hello World 」就更麻烦了。（其实还有 JPA 的其他实现，但是比 Hibernate 门槛更高还不一定有它好用）

上面说得是体系区分，实际应用中，不管是 mybatis ，还是 Hibernate ，直接用都还是更麻烦，还会有上层封装来做可用性提升。像 mybatis 就有 Mybatis Plus （这俩其实是不同开发团队搞的，不应该混为一谈），Hibernate 则是 Spring Data Jpa 。

关于 Hibernate/Jpa 的门槛，需要说一句，它并不只是它们本身的学习门槛，而是设计理念和开发过程门槛：你不一定非要用 DDD ，但一定是拿「实体」或「模型」来作为需求或业务的主要描述语言。

@LeeReamond #9 你再好好想想，别数学是体育老师教的。

最完全的策略，永远只有一个：不要安装不信任的软件，如果不得不安装，装沙盒、虚拟机、或者物理隔离机器里面。