@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 自动机的过程中直接把标签信息冗余到节点上

AC 自动机几乎是多模式匹配的不二解了，你说的“但是因为单条匹配到还要处理业务逻辑”是什么意思，不妨展开讲讲，看到底是什么原因导致了不适用 AC 自动机

@snw 无论是上述两种中的哪一种，最终都不可能推得出 36001*10%-210 这个公式，请正面回答下，这个公式里的-210 这个数值的本质含义是什么？

https://docs.google.com/spreadsheets/d/1smAmln56i3CJyh4vrFQWMzuvIsZlBks7i9Z78E1zfXc/edit?usp=sharing

做了一个表格，如果结合这个表格都还看不懂问题出在哪里那就确实没有讨论的必要了
其中 A 列指定各区间起点，B 列指定各区间税率，C 列中使用公式通过 AB 两列的数据计算出了速算扣除数，是不是和官方文件中正确版本的取值完全一样？然后把 A 列和 B 列换成历史上曾经推出过的文件中的区间和税率，是不是发现 C 列的结果仍然和文件里是吻合的？ F 列是通过超额累进的原始定义的公式来计算税，而 G 列是使用了速算扣除数版本的公式，可以看到二者计算结果完全相同，但是 G 列的公式更简洁，这才是速算扣除数的本质含义

@snw 你一直在强调本质，那请问下，在 3001*10%-210 和 36001*10%-2520 这两个公式里，我可以回答出-210 和-2520 的本质是什么，而在 36001*10%-210 这个公式里，你能说出这个-210 的本质吗？难道就是个为了达到“优惠但又不完全优惠”这个目的而随意添加的一个任意的值吗？你一直强调相比起不减速算扣除数(其实也就是选择了全额累进)来说“优惠”了，如果不想给优惠，那就直接选择全额累进，如果想要给优惠，那就老老实实提供正确版本的超额累进，如果觉得照搬月薪的区间优惠力度太大了，那完全可以根据实际情况去调整区间和税率(也就是表格里的 AB 列)，并且计算出新的 C 列，而不是现在这个结果
政策制定者的真正想法确实是一出罗生门，我们所有人能做的只有分析和猜测，但是从一般人的常理出发，你觉得是
A：原本想要制定一个超额累进的策略，但是没有真正理解超额累进的公式含义，把一个化简后的公式当成了原始公式，搬错了参数
还是
B：出于某些我等 P 民无法理解的苦心，去精心设计了一个形式上长得像超额累进的简化版公式，同时照搬了另一个已有的超额累进公式里的一组参数，然后事后声称这个既不是全额累进，也不是超额累进，而是为了给优惠而精心设计的第三种世界上还不存在的税收算法，所有不理解背后的良苦用心的人都是哗众取宠的小丑
这两种哪种的概率更大？

@changnet 那为什么不能是 36001x10%-2520=1080.1 呢？这难道不是更优惠？说白了，在正确的版本中(比如月薪)，法律文本明确写了，3000 以下税率为 3%，**3000-12000 的部分**按 10%，基于这个前提才算出了速算扣除数为 210 这个数字，所以可以明确地回答以下问题
1. 我国的征税税率是多少？
答：超额累进税率，3000 以下 3%，3000-12000 的部分 10%，等等
2. 计算公式 3001*10% - 210 中的-210 的含义是什么？
答：是对上述的超额累进税率进行计算的过程中产生的一个中间结果，相当于把超额累进当成全额累进计算后多出的部分，减去以后就能还原为超额累进
而在 36001x10%-210 这个公式里，能回答上述两个问题吗？根本就不能，假如把物理公式中的量纲的概念进行一个广义的推广的话，可以说这个公式连量纲都不对

问题的真正本质是，对于一个税收策略的制定者，可供他调整的参数包括：
1. 全额累进还是超额累进
2. 各档次的区间以及税率
至于速算扣除数，压根就不是一个自由的参数，是在当选择了超额累进策略以及确定了区间和税率后自然就确定了的一个值，它的值完全由区间和税率来决定，拿 excel 举例的话，前两个参数是用户可以自由输入的值，而速算扣除数那里放的应该是一个公式，根本就不应该由用户去输入

而由于“减去速算扣除数”那个版本的公式太过于深入人心，导致了很多人，包括年终奖政策制定者，实际操作的人员，以及这个帖子里的一部分人，都把它当成了原始的公式，误以为速算扣除数是一个可以根据各种理由去自由调整的参数，于是把讨论的方向歪到了“速算扣除数应该选多少才合适”上去

政策制定者真正应该去操作的是选择全额还是超额，以及确定区间和税率，如果选择了全额，那么自然就不存在速算扣除数，也就是你们所说的不减或者减 0 的情况，如果选择了超额，那么就应该在确定完区间和税率后重新计算出新的速算扣除数，也就是说对于全额/超额，以及区间和税率的选择，才具备讨论的基础，区间合不合理，税率高了还是低了，在这类问题上才值得各方根据自己的观点进行辩论，而对于一个原本是由其他的参数间接确定的值去讨论取多少合适，以及取值的理由，只能说 not even wrong

@gtx990 @anzu 因为“难道 XXX 不比你懂”、“你笑 XX 不懂 XX 、XX 笑你不懂 XX”之类是反智主义者最喜欢使用的话术，对于认真讨论学术问题的人极尽嘲讽，给对方贴上“读书读傻了”之类的标签，宣扬一些所谓的“看上去很蠢实则精妙”的东西是最容易吸引到眼球的，因为这种东西最容易成为饭桌上的谈资，所以看到这种“反主流”的言论时甚至都不愿意自己去动手求证下，直接就点了赞，甚至都没有发现错误的算法其实压根没有“优惠”，反而还导致了多收税，其实到底是多收还是少收压根就和“制定政策时有没有失误”没有任何关系，可见基础教育仍然任重道远

@mcluyu 因为文件里有三个不同的表格
第一个是《收入按月计算》，也就是适用于广大打工人的，给出了分界点、各档税率和速算扣除数三列，分界点为 3000 、12000 等，速算扣除数为 210 、1410
第二个是《收入按年计算》，适用于劳务报酬等非按月的收入，同样包含三列，分界点为 36000 、144000 等，速算扣除数为 2520 、16920 等等，你看到的应该就是这个表格，其实这恰恰就证明了这种情况下的速算扣除数本来就应该乘以 12
而年终奖是第三种计算方法，只给出了分界点和速算扣除数，分界点为 3000 、12000 等，速算扣除数却是 210 、1440 等，等于抄作业各抄了一半

其实去查一下更多的历史文件就会发现，历史上税率曾经调整过，而每一次的税率更新都会伴随着速算扣除数的更新，并且都是和我前面说的推导过程是吻合的，这也证明了早期政策制定者的本意就是规定区间和税率，同时顺带给出速算扣除数，结果后面抄作业的人把这个大前提给丢掉了，直接抄了速算扣除数，大概就相当于小 A 写了一个计算阶梯税率的函数，先是按原始公式计算的，后面进行了优化，提取出了速算扣除数，而小 B 在照抄这个函数时把它当成了原始的公式，于是只修改了分段点，却没有相应地去修改这些看不懂的 MAGIC NUMBER

简单总结就是，对于政策制定者，需要提供的信息是：税率各档分界点在哪里，以及每一档的税率是多少，这就是制定一个阶梯税率政策所需要的全部信息，至于速算扣除数，是完全由前两个信息决定的，就算不直接写进政策里，实际操作的人自己也能推导出来，这个数是不能独立存在的，也就是说这里看似有 3 个参数，实际上只有 2 个
而到了年终奖这里，却离谱地直接给出了分界点和速算扣除数两个参数，并且速算扣除数还是从另一份表格里搬过来的，最终导致了产生的结果并不是一个合理的阶梯税率，反而成了一个奇怪的锯齿状函数

@PrinceofInj 这个帖子里很多人都没有真正理解速算扣除数到底是怎么来的，我来用小学数学知识从头推导一遍吧，首先说月薪，把前几档的税率列出来如下
(0, 3000): 3%
(3000, 12000): 10%
(12000, 25000): 20%
...
假设工资在(3000, 12000)之间，那么依据上面的税率，计算公式为
(3000 * 3%) + (x - 3000) * 10%
化简一下可以得到
90 + x * 10% - 300 = x * 10% - 210
这就是第二档中的速算扣除数 210
同理假设在(12000, 25000)之间，那么依据上面的税率，计算公式为
(3000 * 3%) + (9000 * 10%) + (x - 12000) * 20%
= 90 + 900 + x * 20% - 2400
= x * 20% - 1410
得到了第三档的速算扣除数 1410
其他的依此类推
所以说 210 、1410 这些数并不是凭空冒出来的，也不是拍脑袋想出来的，真正的本质是阶梯税率，在按照阶梯税率计算的过程中对一些常数部分进行化简得到的结果，脱离了原本的分段点和税率，这些数没有任何特殊的含义
而到了年终奖这里，分段点变成了 36000 、144000 等，但仍然机械地照搬了 210 、1414 这一组速算扣除数，导致了最终的这个畸形的结果

@snw 你自己真正地去亲手推导一遍速算扣除数的来源再来讨论“本质”，现实生活中这种阶梯计费的例子并不少见，比如水费、电费等，只要是阶梯计费，都能相应地推导出各自的一组“速算扣除数”，速算扣除数的值不是拍脑袋想出来的，其真正的含义是当前分段之前的所有完整分段的累加值，因为这部分已经可以视为常数了，所以可以把相乘并求和的结果保存起来，省去了重复计算，是典型的空间换时间的基本操作，所以“减去速算扣除数”不是本质，分段求和才是本质，速算扣除数只是一个中间结果，难道能在计算电费时减去水费的速算扣除数吗？
把月薪的速算扣除数无脑地挪用到年终奖的计算上来，就破坏了“速算扣除数等于前面所有完整分段的累加值”这一根本条件，所以导致了这样一个牛头不对马嘴的结果

@snw 说白了，对任意一个由多条线段首尾相接的分段函数，都能设计出一组“速算扣除数”，是先有的分段函数，才有的速算扣除数，并且速算扣除数的取值由原始函数每一段的斜率决定，脱离了“计算原始函数的值”这个上下文，“减去速算扣除数”这个操作将毫无意义
整件事其实很简单，就是当初制定这个政策的工作人员要么没有理解“减去速算扣除数”这个操作的本质，要么就是一时疏忽，导致得出了现在这个畸形的公式，并且在审核阶段也没被发现，导致了政策被正式发出来，而一旦发出来，再修改就必然会面临之前的错误被暴露，以及权威受损等困境，所以才先射箭再画靶地提出了各种理由来往回圆，说直白点就是继续死扛呗
其实这些小心思作为成年人也都能理解，所以无非也就是苦笑一声接受而已，但是以“难道你比制定政策的人还懂”、“哗众取宠”等理由来嘲讽指出这个显而易见的数学错误的人，那简直就是对大家所受的基础教育的侮辱了

@snw 你才是没有理解本质，月薪之所以有“速算扣除数”的存在，是为了简化分段函数的计算，换句话说税率的分段函数才是本体，“速算扣除数”是在计算这个分段函数的过程中产生的一个中间值，脱离了原本的分段函数，这个速算扣除数将变得毫无意义，而在计算年终奖时机械地减去这个速算扣除数，就跟把质量和温度相加一样荒谬，实际上如果先把年终奖也定义成一个没有间断点的分段函数，然后再推导出一个新的“速算扣除数”，那么这个速算扣除数将会正好是原来那个*12 ，这样的速算扣除数才是有意义的，学数学和物理的人都很容易现在这个计算方法的荒谬之处，荒谬程度就相当于一个连量纲都对不上的物理公式，其实这个政策刚推出之时就收到了很多反对的声音，并且也都指出了这个错误产生的根源，只不过因为某些大家都懂的原因不予修正，同时还提出了所谓的优惠之类的理由来进行找补，但是这些都改变不了“把一个公式的中间结论无脑套用到另一个不适用的公式上是错误的”这一事实

本质原因参见我在 https://v2ex.com/t/856447#reply18 里的回答，其实类似这样的例子在生活中并不少见，比如上学时背的各种口诀、编程里的 async/await 语法、do notation 等等，都相当于一种降低学习和记忆成本的二级结论，但是如果跳过本质而直接记二级结论，一旦超出了适用范围就抓瞎了，从而闹出这样的笑话

@wclebb 打开 iPhone 辅助功能里的朗读选项，让系统读出 emoji 的名称

抓手 - 拆解（:doge