记一次后端项目开发中遇到到坑和解决的方式，希望可以避免更多人遇到同样的问题。
数据库
表不要轻易设置 unique
起因：很多字段是唯一的，所以直接在定义表结构的时候加上 unique 约束。 问题：因为我数据库删除是软删除，所以新加的数据有可能跟已删除的数据造成冲突。 解决：不要给字段加 unique，通过代码来判断，使用 unique 就算数据库抛出错误也不好捕捉处理，所以统一通过代码处理会方便很多。但是如订单编号等还是要加上 unique。
新建表
起因：一开始根据需求设计数据库，然后直接在数据库中创建相应表。 问题：由于开发周期较长，期间还没有开发到的业务改动，然后不停的改动表结构。有时又懒，忘了把无用字段删掉，结果表看起来很凌乱。 解决：只有在开发相应业务的时候再创建相应的表。
代码设计
微信支付
起因：支付接收了来自微信服务器和用户端的两个回调，两个回调共同完成一个订单。 问题：小程序支付完要点击完成才会发起回调，因此没有点击完成就不会回调。用户端还可能因其他原因没有发起回调，比如网络问题，手机卡顿等等。 解决：统一接受微信的回调，用户端只做查询动作。还有，微信回调路径写到配置文件中，因为正式环境跟开发环境不一样。
临界值
起因：商品价格设计，价格必须大于零。 问题：运营想要价格为零的商品。 解决：设计之前最好跟产品和运营确认好，不止是价格，还有各种状态更改临界值等等。
图片存储
起因：图片使用了七牛服务，当时直接把图片的完整路径存在了数据库。 问题：一开始使用的七牛域名会过期，中途换过一次域名，爆炸。 解决：数据中存储相对路径，域名配置在配置文件中，通过 hook 或其他方式进行补全。
封装业务
起因：代码架构主要分了 controller，model 和 model handler(dao)，业务写在了 controller 中。 问题：后来发现某些业务可以复用，直接复用 controller 限制很大，所以直接复制了，然后维护起来很麻烦。 解决：单独分离 service 来写业务，方便维护和复用。
数据状态
起因：没有特意去做什么，注释每个状态码对应什么状态。 问题：例如订单，其实有多种订单，状态有差异，然后改起来很乱，每次都要去看下注释找对应的状态码。 解决：使用有实际意义的常量名代替状态码。
部署
docker部署
起因：因为使用 go 交叉编译后部署，对运行环境没有太大要求，就是用 scratch 作为 go 的容器。 问题：发送 https 请求时会有证书问题，导致请求的服务器不信任我们，请求失败。 解决：使用了 centos 作为容器。
