@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

报名表演大变活人，然后请领导上台当助手配合，让他扎个马步，嘴里叼一卷卫生纸，然后说“大变活人我不会，只好给大家表演个活人大便”，鞠躬，下台

德摩根律秒了

宇宙不是法外之地(doge

首先，rust 的 Option 也是可以使用?运算符链式调用的，只不过由于?优先设计给了 Result ，所以只有当一个代码块里没有出现过将?应用于 Result 的返回时才可以应用于 Option ，否则只要有了一处 Result ，同一个代码块里在 Option 的地方用?就会报错，因为这时候期望的也是 Result ，只要满足了这个条件，对 Option 使用?是完全没有问题的，示例如下
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a4973d87ed8e4d19934952ccb10ce6c6
上面所有认为 Option 没有?运算符并且还强行给出解释的未免有点先射箭再画靶了
不过话说回来，由于上面的限制条件的存在，并且现实中 Result 大量存在，所以能对 Option 用上?操作符的机会确实不多，因为不管 Result 还是 Option 的?，都是为了“像写命令式一样写 FP”这个目的而存在，等你习惯了 if let 解构以后就会发现其实 if let 也挺真香的，到时候自然也不会想要什么?了

其实，“因为这个 App 本身的功能需要上传图片，所以自然需要申请相册访问权限”这本身就是一个典型的误解，不管是前面有人贴出的 Android 的 photopicker 也好，还是 iOS 的 PHPickerViewController 也好，才应该是一个需要发送图片的 App 本应使用的正确姿势，但是可能由于以下原因导致了实际上并没有多少 App 这样用，而是一股脑地申请了相册权限然后自己实现选择器
1. 系统提供的选择器界面无法定制，可能风格和操作方式等与 App 自身整体不符
2. 开发者自身也抱着同样的惯性思维，压根不知道系统选择器的存在，第一时间只想到申请权限的方案
3. 既然大多数用户都已经有了这个惯性思维了，产品顺水推舟，借这个机会“合理”地申请相册权限

上面的这些理由中，只有 1 勉强称得上一个合理的理由，并且哪怕是这样也应该给用户自由选择回退到系统选择器的权力，但是现实情况却大多数都是出于理由 2 和 3 ，导致了只要是一个需要发送图片的应用都无脑地申请了权限

我飘了，居然敢点进来

丧事喜办，传统艺能

看到这条回答的人，以下行为将会依次由自动挡变手动挡
1. 呼吸
2. 吞口水
3. 眨眼

别的不知道，老北京布鞋是真的难以下咽