我用的阿里云的，223.5.5.5 、223.6.6.6 ，有没有大佬说一下优缺点？

如果你的表有几千万的数据，并且值是稀疏的，可枚举的，使用 int 会比 varchar 要少占用很多的存储空间，量变决定质变。

推荐一篇文章，讲解的比较系统： https://mp.weixin.qq.com/s/apUVMfAI52uvc7U-iOVvKg

干嘛一定要刻意的去戒呢，想起来了就放下嘛，主要是怕想不起来，比如在一条腿上面系上一本书啥的。

@fgd 全在这里了： https://developers.weixin.qq.com/miniprogram/product/material/

如果是游戏，还需要出版号，否则不能进行收费，这个已经很久没有发了。

补充一下：

首先是域名，这个需要 ICP 备案，公安备案。
如果是收费性质的，还需要 ICP 许可证。
安卓上架各大市场需要软著。

文化性质的，需要文网文，有 6 类：
1 、游戏类：游戏产品合规运营的准入许可，包含发行游戏币作为游戏里的流通货币；
2 、表演类：利用互联网进行网络在线直播表演；
3 、音乐娱乐类：网络文化经营许可证-音乐娱乐产品类经营；
4 、动漫类：利用互联网经营动漫画视听产品；
5 、展览比赛类：利用互联网进行网上文化产品的展览以及其他比赛活动；
6 、演出剧目类：利用互联网提供演出出节目的传播服务。

@haython 海外不清楚，不过我的认知是功能还是有，只不过没有国内这么严格，这个其实跟运营有很大的关系。国内的你懂的，V2EX 也被 BAN 了很久了。

包括用户的评论、上传、分享等一切 UGC 功能均需要审核，也就是平台自我审查，涉及到这些内容的均要耗费很大的精力来处理。

你说的事务都是技术执行层面的 [如何使用事务] ，猜测一下他应该想问的是业务层面的 [为什么 /什么情况要使用事务] ，一个是 How to do ，一个是 Why to do 。

不过仅从你描述的这些也只是猜测而已，假如说我来进行面试的话，一般就不会问具体的实现细节，而是问这个东西有什么用，为什么要用。

刚才大盘跌 4 个点了，看这阵势是止不住啊

最好在数据库层面进行并发控制，不要在你的应用层加锁。直接加一个字段使用乐观锁来保证在并发的情况下只有一个事务会成功。并且你需要问自己一个很重要的问题，那就是这个业务真的会有大量的并发请求针对同一个订单进行操作吗？

《卷王忏悔录》，开个玩笑，适当放松一下自己吧，等疫情稳定以后出去旅游一下。

如果没有基础设施的支持，不建议用不同的语言来开发。反之，如果用 Spring Cloud 这种的话，基本上就是几行配置就可以搞定，也不需要容器化。

我个人的理解是，每年有一个池子，里面累积的就是你这一年按月份按笔实际获得的收入总额。这个池子的总额达到了相关的及格线（税率表）以后，就按照不同的税率进行交税。

一般来说，公司发给你的工资是已经扣除过的（代缴申报），但是也有没扣除的（或者申报以后实际代缴税额不对），这就需要在清缴汇算的时候去调整，比如我的就是代缴的数额不对，公司就会把那少缴的退给我，让我自己去补税。

这个池子有两个，其中一个就是上面提到的，另一个就是奖金（明年就会取消掉，合并），独立于前者，每一个池子达到不同的及格线（税率表）就按照该税率进行换算缴纳个税。

上面提到的池子都是你的不同收入（个人所得、奖金）独立计算的，一般来说是扣除社保后的实际收入才会算进去。但是还有其他可以扣除的点，这些点就是专项附加扣除，每年按每个项目进行扣除，比如房租 /房贷、赡养老人、继续教育、子女等等。只要符合条件的填写对应的专项扣除，就会从第一个池子里面的总额减去这些扣除额之后再进行个税计算。

以上这些如有不对还请指出，感谢。

不能加索引是因为数据量太大的原因？有没有实际测试过写入的时候性能影响？不要猜测，要动手测试。

gitlab 自带的 CI/CD 已经可以满足绝大多数的需求了吧，内存占用确实比较大的，不过可以调整参数，关掉某些没用的模块。

@wshcdr 简单的来说，你可以把 Controller 里面的一些逻辑转移到一个 Application Object/Service 上。

分析一下原因，按理说每一个接口的逻辑应该是不同的，唯一的，但是不同接口之间可能也会复用到一些应用逻辑，如果这些逻辑在同一个 Controller 的不同的 Method 上（ RequestMapping ），或许可以简单的创建一个私有的方法来搞定这些复用的逻辑。

但是对于不同 Controller 需要复用的逻辑，又不适合放在普通的 Service 上，就可以创建一个 Application Object/Service 来封装了，此时的顺序变成了：

Controller -> Application Object/Service -> (Domain)Service -> Repository/DAO 。

另外再说一些题外话，大部分人应该没有这些顾虑或者思考，看不懂的略过即可：

在 DDD 的战术模式中，领域服务（ DomainService ）一般只对单个聚合进行操作，且这些操作属于该领域自己的业务逻辑，只是不适合放到单个聚合上面，最重要的一点，聚合的任何操作都保证了不变性条件。

但是某一个业务需求可能会跨聚合进行操作，又要保证事务一致，就可能会在上层再建立一个应用层，注意我这里说的应用层跟 DDD 中的应用服务（ ApplicationService ）不一样，它跨聚合操作这种行为本身就是因为模型分析得不到位。因此这种逻辑是不推荐的，因为它模糊了限界上下文之间的关系，但是从编码角度来说却是很方便的。

想一想我有好几个 Service ，然后在 Controller 里面依次调用，只需要在 Controller 方法上加一个 @Transaction 的注解就可以保证事务一致，其中任何一个 Service 失败都将回滚数据，保证数据的一致性不被破坏。但其实这是一种偷懒的做法，或者说在是规模小的时候一种取巧省事的办法。