20 加油

1. 数据库设计和 hibernate 没关系
2. 无非就是分表， 按人分可以， 按天分也可以， 看你的需求
3. 如果一开始就预期到数据量非常大， 而且不需要事务， 那还是用 nosql，mongodb 之类的数据库

自己写一个拦截器不就好了

别惯着
假如说一个小程序的组件需要数据结构 A， 一个安卓组件需要数据结构 B， 但是里面的数据都是一样的， 你需要写几个接口？

简单一点的， 小程序显示 yyyy-MM-dd， 安卓显示 yyyyMMdd， 你要写几个接口？


至于说小程序或者 APP 需要发版本的问题， 那我后端直接给你返回渲染好的 HTML 如何， 热更新， 不需要发版本。

后端保证数据是对的， 前端出 BUG， 导致显示有问题， 你不想着怎么把前端的 BUG 的修复， 而是想着改后端接口去“兼容”前端的问题， 这叫耦合， 前端和后端的强耦合！！

@FrankHB #67
1. 好的架构应该是存储无关的（尽可能）
2. 业务就管好业务， 要有序就在程序中实现， 加一个额外的排序字段就可以了
3. 业务需求作为最重要的核心， 应该是第三方（数据库）依赖于业务需求， 比如数据量大了上 nosql，但是你的业务需求不应该依赖于数据库， 这是依赖倒置原则。
4. 我的测试不会先于需求， 但是我的设计理念高于需求。
5. 需求变化导致数据库变化是正常现象， 数据库依赖于业务！！！变就变嘛， 软件写出来就是用来改的。
6. 不使用数据库的自增主键那么测试就会很简单， 自己写的代码实现的纯业务代码怎么不能测试了。
7. 测试业务逻辑（单元测试）和测试整个系统（集成测试）本来就是不同层面的东西， 二者的需求和测试量是不同的， 也没有任何依赖关系。 单元测试的简单与否与集成测试的可测试性没有关系。


以上观点来自《 Clean Architecture 》

@FrankHB #65 使用自增主键是业务相关的， 但是使用数据库提供的自增组件就是一个具体的实现， 和 DB 强相关， 你的业务和数据库强相关就是耦合， 也就是难测试

windows 的服务依赖一大堆， 又不安全， 从来没想过在公网上使用

取决于你的需求啊 取决于你的读写比
OSS 写入便宜（存储便宜）， 读取贵（下载贵）

比如说：你备份数据库， 每天备份一次， 过了一年发现数据库被删库了， 然后下载最新的备份恢复， 那么就基本可以认为你的需求是只有存储需求， 下载忽略不计。那就用 oss 吧

如果你做文件同步功能， 每天都会去 OSS 同步最新的文件， 那么就是下载为主了， 建议使用自己的服务器

数据库无关， 你的几百行业务代码中， 各种数据库插入就是为了获取自增 ID， 然后给后面业务逻辑用。

如果我们使用 UUID， 那么你的业务代码中数据库操作出现的概率会小很多， 方便测试， 也是一种解耦

@wupher #71 至于你说的某些特别重要的表单， 那么应该是针对几个表单的接口做安全处理， 而不是全局性的

@wupher #71
重放不难防范， 但这个不是我们是使用一项技术的原因。一大堆简单的技术放在一起复杂度还是会大量的增加

@wupher #69
用户提交表单的时候我们默认用户处于一个安全的状态， 比如登录，验证码， 表单签名。

攻击者处于我们系统的最外围， 要攻击必须先突破我们的安全限制才能进行下一步的动作。


你把表单重复提交这种安全域范围内的事情当作攻击， 就相当于你为了预防 1000KM 外的狙击手每天呆在地下堡垒

@wupher #67 攻击==表单重复提交？？

@RubyJack #62 有些人认为接口幂等很简单， 没办法

这么说的话你觉得 tcp 三次握手够吗

@flyingfz #3 说的简单， 前端一个 disable 的事情后端复杂的要死

简单啊，要什么自行车

for 循环一个一个判断啊

不返回你怎么知道你覆盖了什么值