有这技术栈的，大部分不是在黑灰产发财，就是在和政府部门合作

应该是叫沙盒游戏吧。
开放世界类游戏的主要卖点就是弱化剧情束缚，按自己的喜好去探索玩法。沙盒游戏比普通开放世界更自由，游戏只提供了一个大致的世界观和工具，玩家按自己想法去建造和探索就行，剧情是基本不需要的东西。
至于乐高，传统的实体乐高只是搭建，但缺乏和世界的互动。比方说沙盒游戏中你造个房子，可以抵抗怪物攻击，但乐高只能放几个乐高小人过家家或拍照；更大规模的乐高作品太费钱。乐高电子游戏的话，大部分还是剧情类，好像 Lego: Worlds 是沙盒类型游戏，没关注，不清楚怎样。

你先看一下年龄限制，大部分优惠流量卡都限制 60 岁或 65 岁办理。
另外，目前新办的套餐基本上都是长期 29 元起，低于 29 元的优惠期基本上最长 2 年。

没试付费版。Gemini 免费版中文确实不行，不过如果是英文倒是可以……

"Suppose bank annual interest rate is 1.5%. If I deposit $100k in my bank account every year, how long does my bank account balance take to reach $800k?"

看了下在售产品列表页面，只有 SPECIAL 10G KVM PROMO V5 - LOS ANGELES - CN2 GIA LIMITED EDITION VPS 这一款标着 **Refundable within 30 days even if IP is blocked by GFW** 。但由于所有产品都在同一页，所以 Google 搜索结果搜什么产品都容易显示出这句话。

http://bandwagonhost.com/cart.php

另外一个奇怪的现象是，如果使用 Firefox for Android 查看这个页面，有些产品的字体比另一些要大一点，但用桌面版 Firefox 检查元素暂没发现区别，用手机 Chrome 也没问题，不知道什么原因...

https://i.imgur.com/fPBKvcV.jpeg

@charlie21
这里解释一下，劳动法没有规定双休，双休是上面提到的 1995 年国务院令对国家机关和事业单位的规定。企业可以不双休或者不按周六周日休，但仍应满足每周 40 小时、每天 8 小时、每周至少休 1 天的规定。

“第七条　国家机关、事业单位实行统一的工作时间，星期六和星期日为周休息日。
企业和不能实行前款规定的统一工作时间的事业单位，可以根据实际情况灵活安排周休息日。 ”

至于非标准工时制（即不定时工作制与综合计算工时工作制），要点是特定岗位和需要审批，也就是说只有符合限定条件的岗位才能使用，而且必须报经地方劳动主管部门批准，不是企业自说自话就能使用的。
参见《关于企业实行不定时工作制和综合计算工时工作制的审批办法》以及各地制定的规定。

除了《劳动法》规定的不超过 44 小时之外，1995 年国务院发布《国务院关于职工工作时间的规定》，明确规定每天 8 小时、每周 40 小时。
虽然对于企业没有直说双休，但如果单休或大小周的话每天是不能满 8 小时的，否则超过 40 小时违规。

https://zh.m.wikisource.org/wiki/%E5%9B%BD%E5%8A%A1%E9%99%A2%E5%85%B3%E4%BA%8E%E8%81%8C%E5%B7%A5%E5%B7%A5%E4%BD%9C%E6%97%B6%E9%97%B4%E7%9A%84%E8%A7%84%E5%AE%9A

第三条　职工每日工作 8 小时、每周工作 40 小时。

第四条　在特殊条件下从事劳动和有特殊情况，需要适当缩短工作时间的，按照国家有关规定执行。

第五条　因工作性质或生产特点的限制，不能实行每日工作 8 小时、每周工作 40 小时标准工时制度的，按照国家有关规定，可以实行其他工作和休息办法。

@whirlp00l
如果只看公式就容易陷入困惑迷茫。股权激励与全年一次性奖金的业务实质有一些区别。

全年一次性奖金基本上只是对于当年工作的奖励，所以摊在当年月度工资上是合适的。而且年度奖金金额与当年的月度工资一般是相称的，所以要实现“在实际月度工资边际税率上累进”时使用奖金/12 查表作为近似税率一般只低不高。

股权激励实质则是对于过去若干年的工作奖励，如果要摊的话照理应该摊到整个限制期间，短则 12 个月、长则 60 个月，差别较大。同时由于跨越时间较长，且行权方式不同（一次性、多次），难以用本次行权所得去估计被摊月份的边际税率。所以套用全年一次性奖金的思路不太行，才改用“分摊到凭空多出来的月份，但不超过 12 个月”这种妥协的设计。

顺带一提，现在个税改革为年度综合所得，其实只解决了月与月之间收入分布不均匀（比如全年一次性奖金），但并不能解决年与年之间收入分布不均匀（比如股权激励，比如离职一次性补偿）。再拓展一下，即使解决了时间分布不均匀，总还有其他维度的问题，例如家庭成员之间收入不均匀（比如一方高收入、另一方无收入），这些都是要不断改进的。

@GuuJiang
你的话就原封不动地送还给你：
没想到你的理解能力低下到这种程度，就不要在这里继续浪费公共空间了。
友情提醒你一句，V 站一般情况下无法删帖，希望你若干年后回想起来不要后悔在这里留下的黑历史。

你一大堆废话我都不厌其烦地看完，耐心地逐一给你指出你错在哪里，给你解释什么叫业务逻辑，你倒是连看都不看，自始至终只是复读自己的错误认知。
带你到这个程度你都理解不了，确实没有任何讨论的必要了，祝你春节快乐算了

@GuuJiang
我已经反复解释业务逻辑了，而你压根一点都没理解或者尝试理解。

你说方案 A“也没有那么的困难”、“实际也没增加多少困难”？真是随口就来。你知道 19 年前在实操中这个方案会导致多少麻烦和障碍吗？
在“年度综合所得”这个改革之前，个税一直是单月计算的。这是什么概念？就是说计算当月个税只需要当月数据就可以确定，不需要其他月份数据，请记住这点。
2005 年那时大部分公司的人事工资数据没数据库，一个月工资表就是一个或几个 Excel 文件（甚至纸质计算表），年终奖可能是另一个 Excel 文件。现在你要分摊奖金到每个月，那么意味着你要给每个人每个月重算一遍个税，要从一堆文件夹里找到打开一堆文件，找出以前每人每月应税收入多少、实缴多少税，然后还要汇总起来（复制值或用 Excel 公式外部链接）；要是想检查一下又得打开这一堆文件。这是增加了 n 倍工作量！而且由于算法不同，还要另做 Excel 公式，但当年就连会计普遍水平都一般，更别提许多企业是人事算工资，计算能力只会更差。
另一方面当年税务局系统也是按单月计算设计，你想取以前月份的数据？不好意思系统不支持，先申请个系统大变更吧，在系统支持之前税务局想核查申报数据都难。
你觉得这些不是大事？那么好，年度奖金不一定在 12 月发，有些企业是年头或年中发，发放当月只有以前几个月的实际数字，请问你怎样分摊计算缴纳奖金个税？你想说先按摊给后面几个月算一次税（即基数为零，税偏低），等后面几个月发工资了再合并重算？那后面几个月的工资表也得一直带着这个分摊数，麻烦事。
你如果觉得还不难，那么好，现在员工跳槽换了家公司，请问下家怎样拿到这人前几个月应税收入和已交个税数据？员工不知道，上家懒得给，税务局也不好查。
等你把这项那项困难都解决了，仔细一看，这不就是现在的“年度综合所得”吗？但你站在 2005 年，你能说先等你花 15 年把一切准备妥当了再出政策吗？

接下去，你对方案 B,C,D 的业务语言描述完全就是错的。
方案 B 的业务描述是：把年终奖分摊到*实际*的 12 个月，与月度工资合在一起适用差额累进。但由于方案 A 实操困难，所以做了假设和简化，例如假设年终奖除以 12 适用的税率与月度工资达到的边际税率基本相仿或更低，例如由于不知道工资边际税率那档还剩多少才达到下一档所以后面就不再累进，最终结果就是按照年终奖除以 12 查到适用税率计算。
方案 C 的业务描述是：在方案 B 的基础上再适当减一个不大的数。虽然看起来不如方案 B ，但至少大致保留了方案 B 的逻辑，并且实操中公式形式与月度收入个税一致，也不需要多一个查询表。

方案 D 的业务描述是：把年终奖分摊到*凭空多出*的 12 个月，从零开始使用差额累进。这完全就是另一套错误的业务逻辑，是最没资格参与对比的！
如果你稍有税务实践经验就知道，凭空给从零基累进是非常大的优惠，根本不是你以为的减除数多一点而已。你还不明白的话，你看看你自己的例子：
* 方案 B 税款 3600.1 元。
* 方案 C 税款 3390.1 元，比方案 B 少 6%。
* 方案 D 税款 1080.1 元，比方案 B 少 70%！

另外你就别瞎扯量纲概念了，量纲分析适用于大部分理工学科，但这里讨论的是经管学科明白吗？这里的公式是人为定义出来的，公式中的数字就是纯数字，压根不鸟量纲明白吗？
比方说签一份合同，合同中规定如果逾期违约，那么违约金 = 拖欠金额*(拖欠月数)^0.5 ，你难道跳出来说"不对，这公式左边单位是元、右边单位是 元·月^0.5 ，量纲不对所以显然是错的” ？？？
P.S.，“月”是单位，不是量纲，谢谢。

@Padawan
地税局或地方国税局可能会有你说的这种情况，但这是国税总局发文，而且不是针对某个(些)纳税人的定向政策，不要太想当然了。

@GuuJiang
再读读 120, 145, 150 楼吧，你仍然没有理解我重复了很多遍的业务逻辑。

速算算法本来就是怎么简单怎么来，而不是什么好理解。你给出的月收入“速算添加”算法并不比速算扣除有什么优势，甚至实操上更麻烦（多一个参数），2005 年仍有不少企业的工资表是手动算的（纸+笔+计算器），多减一个数就多一分工作量。

顺便说一句，如果平行宇宙的税务局把“速算扣除”算法套用到全年一次性奖金计算上，那么减的边界数也会是按月度表来的，结果仍是跳增而非跳减🐶
36000*3%=1080
(36001-3000)*10%+90=3390.1

@GuuJiang
我 145 楼、120 楼等已经重复解释过很多遍业务逻辑了，如果你思路还转不过弯来那我真没办法教会你。

最后实现的公式不需要你所谓的一一对应的“意义”，你讨论一大通公式哪一部分具体对应什么东西是没意义的。

@GuuJiang
你会提出全额累进，以及你提出的参数建议，说明你压根没理解业务逻辑。

请理解(1)“把年终奖摊到 12 个月的月度收入之上继续适用超额累进税率”与(2)“把年终奖摊到额外的 12 个月，每个月单独适用超额累进税率”这两种业务逻辑的区别。

对于第 1 种，实操中还需要由人事/会计给每个人添加每个人月度收入的参数，并且这个参数每月是不同的，并且如果一次性奖金不是在最后一个月发你都没法确定这个参数。
对于第 2 种，从业务逻辑上就不是这样设计的。

@chairuosen
首先，上面提出的那些简单的改 bug 方案是违背业务逻辑的，这比一个有部分意外结果的不优雅的业务逻辑更糟糕。
其次，这个问题已经被“年度综合所得”方案彻底解决了，所以剩下的问题只是什么时候把过时补丁删掉罢了，不需要再修改补丁。
最后，老用户也是用户，所以政策变动一般会考虑延续性。

@kkbblzq
并不是唯权威论。我已经介绍了前因后果，也没有认为这个方案没问题。我想说的是，你们能想到的“正确方案”要么错得更大，要么不具可操作性。另外，彻底的修正已经上线了，没必要再改这个临时的补丁。

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