这不是一个合法的掩码，掩码必须前面若干个 1 后面跟若干个 0

如果我有罪，请让法律制裁我，而不是让我去读非等款字体显示的代码

恭喜你发现了 go 的一个致命伤，例如 Haskell 中的 Either 、rust 和 swift 中的 Result 等等基于 Monad 的返回类型，都应该是一个 sum type ，然而 go 却定义了一个 product type

兴致勃勃点进来，骂骂咧咧退出去，这不是我们想要的车牌加密

@MapHacker 请问你考虑入党吗:doge:

想要 netstat 看到是不可能的，除非你自己魔改一个 netstat ，前面所有答案都没有审题吗？
答案就是，不要拘泥于 netstat ，而是在具体的应用里识别，因为不管是 xff 也好，代理协议也好，都是把真实 ip 作为应用层数据的一部分携带过去，后端需要自行提取

现在还算好了，以前只要弹出来屏幕就保持常亮，经常因为这个莫名其妙地没电了，后来苹果还专门针对这个做了个更新，去掉了常亮

https://v2ex.com/t/825137#reply7
经典陈年老 bug ，不同人在不同时期遇到的触发词不同，只要习惯使用拼音输入法输英文的时不时总会遇到

@snw 醉了，没想到你的理解能力低下到这种程度，反正这个帖子肯定也已经沉了，就不要在这里继续浪费公共空间了，如果你还想要继续讨论，就去知乎上开个提问，让更多各行各业的人都参与进来，只想友情提醒你一句，V 站一般情况下无法删帖，希望你若干年后回想起来不要后悔在这里留下的黑历史，最后回复一条，此后不会再在这个帖子里回复，大过年的，你自便
你一直扯业务逻辑业务逻辑，什么叫做业务逻辑，以月收入为例“月收入实行超额累进制，3000 以下税率为 5%，3000 至 12000 部分税率为 10%”，这就叫业逻辑，并且白纸黑字地写在了法律条文里，有了这个业务逻辑，在使用速算扣除数计算时，这个速算扣除数就只能是 210 ，不可能是其它任何一个值，否则就违背了前面的业务逻辑，所以 210 不是人为定的！不是人为定的！不是人为定的！是根据“月收入实行超额累进制，3000 以下税率为 5%，3000 至 12000 部分税率为 10%”这个业务逻辑推导出来的，这点都理解不了还讨论个屁的业务逻辑，要是月收入那里敢以任何的理由在 5%、3000 和 10%这几个数字不变的前提下把 210 改动任意一点，你猜会不会被喷出翔，年终奖那里吃亏就吃亏在没有把“超额累进”这四个字明确写出来，所以给你们这种人留下了一点诡辩的空间
至于方案 B ，只要是只以年终奖除以 12 的结果去月收入表里查税率，那就跟方案 D 一样都是分摊到额外的 12 个月，这点都理解不了，确实没有任何讨论的必要了，祝大家春节快乐

@snw 本来我还觉得你前面说的从业务逻辑角度出发的分析还体现出了你比其他人更理性的一面，别人喷你喷得有点冤，但是从这里的回复看你已经开始逐渐往为杠而杠的方向上发展了，好吧，我继续回应
你要说“速算增添数”不比“速算扣除数”优秀，OK ，我同意，因为这本来就不是这个类比的重点，这个类比是想要说明，无论“速算扣除数”还是“速算增添数”，在计算上都是完全等价的，因为它们分别都是从超额累进的原始定义出发推导出的两种中间结果，这两种中间结果在正确使用的前提下都没有问题，但是一旦忽略了适用条件产生了误用，就会形成完全相反的结果
你说的应该是-3000 而不是-36000 ，这个错误简直比起“-210 还是-2520”那个错误还要离谱，但是好处是足够明显，所以也许可以作为一个很好的切入点来帮你理解-210 到底错在哪里，先叠个甲，接下来我会使用一些需要具备一定的抽象思维能力才能理解的不严谨的设定，如果你理解有困难，请自行去咨询学数学和学物理的朋友，让他们给你解释，如果我们给前面出现过的所有公式里的一些数字添加上量纲，年终奖的数字量纲为“元”，12 的量纲为“月”，那么元除以月得到了“元/月”，“元/月”乘以月得到元，于是你就会发现 36001 这个和 3000 这两个数字的量纲都不一样，而量纲不一样的数字之间根本就不可能执行加减运算，其实原本的那个错误里之所以-210 应该变成-2520 ，根本原因绝不是像你想的那样“一群数学家为了让数字变得好看而强心凑上去的一个值”，而是乘以 12 后把量纲从元/月变成了元，这样才能和元进行加减运算，“速算扣除数”和“速算增添数”的两个例子里，都是减去或者加上了一个量纲不正确的量，而一旦把量纲修正了，二者都能同时得到正确的结果 1800.1 ，这从另一种角度揭示了原本那个错误的本质

@GuuJiang 上面第 6 段里有处笔误，“全额累进”应为“超额累进”

@snw 我完全充分理解你想要表达的所有观点，但是反过来你却并没有理解或者说尝试去理解我的观点
我来从头理一遍你的逻辑，然后一一指出你的逻辑里有哪些陷阱
1. 如果把年终奖并入当月工资计税，会导致税收太高，对劳动者不公平，在这个背景下税务部门开始制定新的税法，这点我完全同意
2. 接下来有 4 种备选方案，按缴税额从高到低依次称为 ABCD 下面我来逐个分析
3. 方案 A：也就是你说的本质，即把年终奖分摊到 12 个月中去合并计税，并且以原本的月收入为起点继续超额累进，我完全同意你说的这个才是年终奖税本来应该有的样子，这个方案对国家来说是最公平的，但是**直接计算年终奖的税**实操较困难，这点我也同意，但是实际也没有那么的困难，只要抛开直接计算这个固有观念，先把分摊后的部分累加以后整体算一个税，再减掉之前月收入已经交过的税，是不是就解决了？实际也没增加多少困难
4. 方案 B：36001*10%，不减速算扣除数，用业务语言描述，相当于把年终奖分摊到凭空多出来的 12 个月上，然后进行全额累进
5. 方案 C：36001*10%-210 ，也就是现行方案，用业务语言根本无法描述
6. 方案 D：36001*10%-2520 ，用业务语言描述，相当于把年终奖分摊到凭空多出来的 12 个月上，然后进行全额累进
7. 约定完上述记号后，我们来一起逐条分析你的逻辑，首先，你说方案 D 的问题是“210*12 后导致了实际上相当于分摊到了凭空多出来的 12 个月，偏离了本质（其实就是说离方案 A 更远了）”，但是你发现没，这个问题在方案 BCD 中都同样存在，造成这个问题的根本原因是重新以 0 为起点计算税率，只要选择了以 0 为起点计算，自然就已经造成了这个结果了，和 210 乘不乘 12 根本没关系，也就是说在“偏离本质”这个缺点上，BCD 之间只有量变没有质变，大家都是 50 步笑百步而已
8. 其次，你说方案 C 比方案 B 更优惠，从结果来看确实没错，但是和上面类似，要说优惠的话 BCD 都比 A 要优惠，并且带来优惠的大头贡献仍然是“重新以 0 计算起点”，和这个相比，后面的速算扣除数减多少对于大多数人来说已经无关痛痒了，C 相比 B 带来的仍然只是量变而非质变
9. 所以你的所有逻辑无非就是，C 比 D 更“接近本质”，比 B 更“优惠”，所以 C 是最优的选择，我没有总结错吧？这里就体现出你的一个陷阱了，要寻找一个平衡的方案这点本身没有错，但是应该是在 A 到 D 这个范围中寻找，而不是在 B 到 D 这个范围，碰巧 B 和 D 的公式长得只相差后面的速算扣除数，于是造成了“减去一个介于 210 和 2520 中间的数是一个更合理的方案”这样的假象，并且夸大了方案 C 对于两种优势的贡献程度，成功把部分人带进了沟里，得出了“虽然方案 C 不合理，但是方案 D 更不合理，并且方案 C 比方案 B 更优惠”这样一个很具有迷惑性的结论
10. 而我的观点是，我完全同意应该综合考虑公平性和易操作性，去寻找一个介于 A 和 D 之间的方案，这个目的应该通过制定一组新的区间和税率来完成，而不是去修改公式里的速算扣除数，虽然说从业务出发-2520 似乎离 A 更远，但是从数学角度出发却是“选定了 36000 和 10%”这个前提下的唯一解，你说的“把-210 改成-2520 只会造成更大的不平衡”这个观点看起来好像很有道理，问题是造成这个不平衡的是从数学角度出发支持把-210 改成-2520 的那些人吗？不是，而是选择了 36000 和 10%的那个人，从它选择了这组数那一刻起，就已经决定了后面只可能是-2520 ，你为什么不去抨击选择了 36000 和 10%的人而要反过来抨击指出数学不合理性的人呢，为什么仅仅因为-210 看起来更平衡而宁愿选择放弃数学合理性，而不是去选择真正合理的方案：即调整 36000 和 10%这两个数呢？
11. 方案 ABD 都值得拿来讨论和对比，因为他们各自都具备明确的业务含义，而方案 C 连参加这场对比的入场资格都不具备，因为他是一个不自洽的，无法用业务语言来描述的畸形方案，你比起直接认为应该无脑改 D 的人来说确实看得远了一步，但也正是这种自信蒙蔽了你的双眼，拒绝去思考方案 C 的天生缺陷，我从头到尾都没有去讨论过 C 和 D 哪个更优的问题，一直都只是在论述为什么 C 不具备成为备选项的资格，包括我举的那个思想实验的例子，也是换一种角度指出滥用量纲不正确的公式会造成多么荒谬的结果，如果你无法理解这个实验和现实情况之间的联系，以及为什么应该-36000 而不是-3000 ，真心建议你好好补习下数学中的抽象思维能力
12. 然后就是最后一个问题，为什么有那么多的人指出-210 应该是原本-2520 的误用，因为这个错误首先太明显，其次里面有太多的巧合，“工作人员充分地思考了各种方案的利弊，为了寻找一个合理的平衡方案，哪怕明知将来要被骂，也要自己默默承担一切，坚持为广大劳动人民谋福利”这种可能性的说服力远远比不上“当初可能根本就没想那么多，本来就是想直接设计出方案 D ，并且懒得再单独给出一组分界点为 36000 ，扣除数为 2520 的表格，而是让实操人员除以 12 后去查 3000 的那个表，结果无意中搞错了 210 的倍数”这种可能性，只不过在被爆出问题后，事后诸葛地发现了“方案 D 同样也不合理”这一理由

@snw 是你一直思路转不过弯来，一直没有明白“速算扣除数”不是一个可以由制定业务逻辑的人指定的值，他能够指定的只有区间和税率，速算扣除数是实现层面的产物，所以“速算扣除数取多少值合理”这个问题从根上就不应该拿来讨论，如果你想要反驳这一点，请正面回答我前面提出的几条疑问，而不是用一句“不需要意义”搪塞过去，如果你所认为的业务逻辑居然连“用普通人能理解的自然语言描述”这一条都满足不了，而是要借助另一个业务在实现过程中产生的公式来描述，你觉得那可以称为一个业务逻辑吗？连描述里面涉及到的每一个常数的意义都解释不出来，还能称之为一个业务逻辑吗？
如果这还是理解不了，不妨来做个思想实验，假设在另一个平行宇宙里，最开始的月收入那个版本给出的值不是一个“速算扣除数”，而是一个“速算增添数”，取值如下表：
(0, 3000): 0
(3000, 12000): 90
(12000, 25000): 990
并且把计算公式修改为(x - 所属档次的起点)*所属档次税率 + 速算增添数，比如 12002 的所得税=(12002-12000)*20%+990=990.4
这个“速算增添数”是不是比“速算扣除数”更优秀？
第一，速算增添数的计算变得更简单了，下一行的速算增添数可以在上一行的基础上递推
第二，最终的公式变得更好理解了，更加直观地体现出了超额累进的过程
那么假如把现行的月收入的政策中的“速算扣除数”替换为“速算增添数”的版本，相信你不会有意见吧？因为这样的修改对最终税收的计算不会有任何影响，和“速算扣除数”的版本原本就是完全等价的

好了，接下来在这个平行宇宙里，接着重演年终奖的故事，那么最终的版本就会变为
年终奖 36000 的人，税为 36000*0.3=1080
而年终奖 36001 的人，则变成了
(36001-36000)*10%+90=90.1
于是网上讨论的标题不再是《年终奖多发一元，到手少千元》，而是变成了《年终奖多发一元，到手多千元》，那你觉得在这种情况下，从有人指出有问题到税务部门修改算法，需要经历几天？

月收入明明采用了两种完全等价的方法去定义，但是相对应的年终奖却产生了两种截然不同的结果，你觉得问题出在哪呢？仔细想清楚这些问题，再决定要不要继续坚持你的观点吧

@snw
> 我是(半个)业务部门，我很讨厌开发用“代码优雅性”、“我觉得应该怎样怎样”来试图直接篡改业务逻辑。
由业务逻辑导致的意外结果，而且有 workaround 的情况下，应该先制定业务逻辑的改进方案，而不是想当然地直接改代码。

引用你自己说的这段话，什么叫作业务逻辑？“3000 以下税率为 3%，3000-12000 的部分税率为 10%”，这种才叫业务逻辑，因为它是用自然语言描述，并且也白纸黑字地写在了官方的文件里，任何一个读懂了这段文字的人都能够计算自己应该交的税，比如我工资 5000 ，交税 290 ，我能对照着官方文档中的业务逻辑清楚地知道每一分钱的来龙去脉，5000 当中的 3000 按 3%应交 90 ，另外 2000 按 10%应交 200 ，合起来一共 290 。这个过程中是不是完全没有用到 210 这个数字？因为“3000 以下税率为 3%，3000-12000 的部分税率为 10%”这段文字已经使用描述一个税收政策所使用的通用语言给出了这个政策的全部信息，至于 5000*10%-210 ，反而不属于业务逻辑，而是实现层面的其中一种选择，实现者可以选择用这个公式，也可以选择不用，总之只要从原始的业务逻辑出发，一定能够得到正确的结果，而过去的文件把某一种具体实现中推导出来的一个常数也写在了业务逻辑里，本身就是不合理的，也为后面的事件埋下了伏笔，因为把 210 写到文件中，首先就在业务逻辑中干涉了具体的实现方式，其次这个 210 和前面的税率其实是在使用两种不同的方法描述了同一个业务逻辑，那就给制定业务逻辑的人增加了额外的风险，就是必须要维护这两个数字之间的一致性，比如已经说了“3000 以下税率为 3%，3000-12000 的部分税率为 10%”，那后面对应的速算扣除数就只能是 210 ，根本没有别的选择，一旦变成了其他的数字，就会和前面的描述自相矛盾，并且每次调整了区间和税率时，扣除数必须得要跟着一起变
而后面的年终奖恰恰就踩中了前面埋的这个坑，在 36001*10%-210 这个例子中，根本就做不到像上面一样使用自然语言描述出 36001 中哪一部分的税率是多少，别说 210 了，连 10%都变得无法解释，因为你根本就没法说清楚 10%到底表示哪一部分的税率，这难道不属于业务逻辑有 bug ？
只要是人都会犯错，权威也不例外，一个有错误的文件已经正式发布了，那么在被修改或者废止之前就只能照着执行，这个大家都可以理解，哪怕去论述为什么不能修改，也勉强可以接受，但是非要去说“原本就是故意这样设计的”、“这是更优的选择”，那就简直是在把大家当傻子了，原本这个错误知道的人也不多，从这个帖子的讨论就可以看出很多人也是第一次才知道的，哪怕知道也并不一定完全清楚细节，你非要坚持不余遗力地去为之辩解，导致更多的人了解到这个错误是多么的低级，税务部门内心表示听我说谢谢你

@print1024 这个完全不是问题啊，首先 AC 自动机命中时本来就知道是哪一个关键词命中的，再额外维护一下从关键词到标签的反向关联不就行了，更简单的是在构造 AC 自动机的过程中直接把标签信息冗余到节点上