@iyaozhen 屁股决定脑袋。你所谓的对业务的监控，是指想知道业务挂了，这个问题本来就属于基建。我也说了，如果业务系统里发现有基建问题，硬生生抓住包成一个 200 抛回给调用方，这个我也不能接受的。但很多莱塞特福原教旨主义者想要做的是把业务逻辑层面的错误也给放到 HTTP 状态码里，比如一个大学生离校系统里要去查学生在各个单位的业务是否已结清，我一个图书馆系统的接口发现还有书没还的时候，给他返回 HTTP 200 再加一个 JSON 表示业务层面这个操作不成功，但我的系统没挂，调用方传进来的参数也符合 schema ，权限也对，所以在 HTTP 层面我认为没问题，不应该返回错误码……有人说这样不清真，应该改成在 HTTP 码里把这个当“错误”来返回，不能塞进 200 的 JSON 里。这不是扯鸡巴蛋吗。总不会有人为了方便监控离校系统调用图书馆系统接口时的业务逻辑错误率而想把我千奇百怪的业务错误码从 JSON 里提出来放到 HTTP 状态码吧。

当然，我坚决反对 JDBC 连不上数据库服务器的时候抓出来异常还要包到 200 里向上返回……业务逻辑上的错误（责任在甲乙方最终用户，不涉及基础设施运维）用 200 包起来返回是一个美丑的问题，基础设施错误还要这么搞，是沙雕还是沙壁的问题。

至于拿监控说事的……监控啥？

如果是为了监控基础设施，我 JSON 里封的是业务逻辑层面的错误，关你基础设施屁事？

如果是为了监控业务错误，却嫌错误代码封在 JSON 里不方便……你就是想让我把业务错误代码放到 HTTP 里去对吧？你是不是觉得我这边各种各样的业务错误怎么映射到 HTTP 那几个状态码里很简单？你个普罗米修斯崽懂个屁的业务。

我的业务 API 又不只是为了让你来做监控而存在的，我要给别的业务单位调用啊。HTTP 状态码没出错，业务状态码出错的时候，可以去找管业务系统的人处理，HTTP 状态码出错了找管基础设施的人处理，这两拨人不是同样技能的啊。业务端有个什么狗屁错（而且还不是那种 unrecoverable 的外部环境错，是业务逻辑的错，要业务用户处理的）都返回成 HTTP 错误码一级一级传上去，查个业务级错误都要基础设施的人联动，这是制造民怨吗？你来给我做基础设施架构让我有办法一键定位出错的层次和节点吗？可是我只能拿到够做业务功能的经费，而且是单个单个项目做，没有做基础设施的条件，我让一个行业人士起家的地方性行业性中小型业务信息化开发商给我做业务系统开发的时候顺便免费做一套云原生的微服务的可观测的可这个那个狗屁的基础设施，并且以后的其它同类业务开发商要逼着他们不允许用自己的积累，一定要做在这些所谓现代的平台上，这忒外祖母的现实吗？

@adoal 我这么说倒不是反对用 HTTP 状态码表示业务状态，而是说要想清楚以自己的团队和周边状态、项目背景、后续配套支持力度，甚至是组织机构设置、职权划分、撕逼流程，这样做是否真的能把事情做得更好，需要付出什么样的代价，做得更好的结果是否会引发其它可能的问题？工程上做选择都是 trade off ，有些看起来好的，能不能落地好是要结合实际的。

@jorneyr 你不是没说清楚，是没理解别人的答案。别人的意思大多都是让你换用支持 VPN 的路由器设备。不过这个事其实可大可小，往大里说可以问运营商卖 MPLS VPN 服务，这个可以做到全透明的，你自己的路由器都不用配置。不过看你表述，只是“可以购买路由器”，那应该不会花这种钱。网友们推荐的 WG 、ZT 之类的，看样子你们也未必有人能搞定技术门槛。那……关键词“蒲公英”可以看看。就是做向日葵远程控制的那个公司出的硬件。

用 HTTP 状态码表示业务结果，需要对业务和技术都有深刻理解的老司机做精心设计，否则会画虎类犬。
HTTP 状态码数量就那么一些，而业务的结果状态数量是不可控的，随着业务接口膨胀起来，如何映射到 HTTP 状态码的分类，如何表示业务状态细节，都不是空口说一句优雅、规范就能解决的，是要实打实一个个干出来的，要踩坑踩水甚至踩屎的。
在实际架构中，可能经过 API 网关以及其它各种反代和中间件，业务状态逐级向上传递，业务状态码跟基础设施状态码在同一个命名空间，必然会导致设计工作量和难度更大。
最后，在 HTTP 状态码的命名空间里表示业务状态，受惠最大的其实是做系统运行状态监控的。但，同样的问题，如果没有业务和技术都足够资深的老司机来做设计，很可能出现监控信息的无序，失去意义，甚至搞出用 AI 过滤有效监控异常的笑话。
先不说团队素质、集成方团队素质、遗留系统对接之类的非技术问题吧。
总之，理想很美好，但是，陈皓给用户方做咨询的顾问团队能做好的事，不等于人人都能做好。

申请国家核高基（误

其实你在 Linux 下的做法也不地道。Linux 下，在生产环境跑的守护进程，当代的主流做法是写一个 systemd unit 来做启动控制，而不是用交互登录的帐号手工启动。Windows 下也是同理，要做成服务。

满满的人文关怀👍

执行力真棒

商用补贴民用。民用宽带的质量是政治任务，只好贴钱，通过商用宽带的商业手段割羊毛补回来。

以前我们中层领导在拉我们部门开会时说过一句话：我这个外行来的领导现在能在 XXX 界得到同行尊敬，是因为上级任命我坐在这个位置上，一但把我调离，XXX 界的人遇到我根本不会理我，只有你们在这个行业有积累的专家才会不管坐什么位置都能一直得到同行尊敬。

当然，这并不能改变我们必须听他命令的事实，不论是否合理，内行外行。

我见过的商用品牌机都是负压。商用机就是个干活工具，换代很快，没必要为了精心呵护做正压设计。

同意 #21 ，主要还是键盘厂商太卷了

@yuedashi 呃，不关我买线的事…我忘了加引号，忘了加狗头，表达不严谨，忘了让你看出我只是想跟 op 表达买快充线的大多数人根本不会拿来传数据所以商家为了迎合它们又能减成本是合理的商业行为，行文不严谨让你误以为我是想说不需要 d+ d-来协商就能用的纯 5v 非快充充电线是我的错。

早知讲话不严谨会惹这麻烦我还不如一开始讲严谨，是吧。先不严谨再事后解释好特喵的累😔

何来“几个语言都是输出 831926”，“CPP 和其它语言不一致”。

如上所说，C 里的整数运算算完除法之后结果还是整数，本来就不带小数部分的。其实用 ceil 函数截一下是多余的。
你在 Python 2 里运行 (1 * 33 + 49297) % 23680 * 10000000 / 23680
或者在 Python 3 里运行 (1 * 33 + 49297) % 23680 * 10000000 // 23680
（因为 Python 2 的 /是整数除法，3 里 /是保留浮点结果，//是相当于 2 和 C 里 /的整数除法）
结果也是跟 C 一样的 831925 。
目测区分整数和浮点数的语言里全程用整数运算结果都应该是 831925 。

@yogogo 系统会被入侵的根本原因是有漏洞，SE 对系统的保护主要体现在即使因为有漏洞被爆栈了但可以限制服务进程被控制做其它动作的权力，把损失尽可能降低，但漏洞还是客观存在的，危险还是存在的，比如从系统层面是合法操作但会修改业务数据。所以尽管 SE 能保护系统免受某些侵害，但该修的漏洞还是要修的。

另外就是假如系统运维人员在部署应用软件时遵循 FHS 和发行版 packaging 的规范，SE 会保护得恰到好处，但很多人在没有学过规范的情况下会根据师傅传授或者网上搜来的自己乱搞一套，SE 就处处捣乱了，这时候只会开或者关 SE 就不够用，要去根据实际情况配置 context 。

所以很多习惯非规范的老司机针对初学者写的攻略往往第一件事是关 SE……而对初学者来说要玩转 SE 确实也不容易。

呃，竟然开着 selinux 玩……遇到的大多数人装了 RH 系之后第一件事就是关 selinux ^_^