个人觉得这个设计没什么问题，基本上预留一些升级的空间。上线一段时间后，新增需求，改数据库是非常要命的一件事。而且正规的流程，开发人员很可能没有权限操作数据库，还需要 DBA 的配合（甚至行政手段的接入），生产环境飞针走线，太可怕了。

至于可读性差，确实没什么办法，预留接口，天知道到时候甲方爸爸会提出什么需求来。全靠文档支撑。

@ming #26，我国是采用的大陆法系，因此判例只有指导意义，具体实务中是以当时负责的合议庭判断为准，如果以有先例判罚不同为由提起上诉，获得支持的概率不能说没有，但真的很低。这是明显不同于美国的海洋法系。

（ 2020 ）川刑终 528 号: https://wenshu.court.gov.cn/website/wenshu/181107ANFZ0BXSK4/index.html?docId=5f5be2bf001e4d27a786aca0000b1a50
（ 2019 ）苏 0812 刑初 49 号： https://wenshu.court.gov.cn/website/wenshu/181107ANFZ0BXSK4/index.html?docId=1ccaf4ba35794f428b99ab26011a09a3

司法实践中，特别是侦查机关是有逮捕指标的，极个别一些基层办案人员，为了完成自己的指标，某些行为，可以行政处罚，可以刑事立案，就上纲上线变成了刑事案件。得益于近些年上层的要求，检察机关需要控制批捕率和逮捕率，这其中的有些涉案人员，最终会以检察机关做出重新侦察的决定，而被释放。通常这类案件被羁押人员在 7 天左右就被释放了，而他们自以为是行政拘留，实际上这是可以申请国家赔偿的，本质上是采用的刑事强制措施。

公检法司是一家，一家人就一般不会打脸。而入口大概率是侦察机关，抓了人进来通常就不会无罪放出去。
而法院体系没有传统意义上的上下级关系（行政级别依旧有），因为上级法院只能指导下级法院，而且一般也不会主动去指导。
公与法之间又没有隶属关系，侦察机关的法律素养远低于检察和审批机关。所以最高法的指导其实对于基层来说，意义真的不大。
除非是涉案人员有较强的社会影响力，引发的公众的普遍关注。

@ming #24 非法经营在司法实践中，被极大的滥用。可以翻看现有公开的裁判文书，非法经营已经和寻衅滋事一样，成为标准的口袋罪，是典型的兜底型罪名，只要有经营活动，不论是否盈利，都可以被认定为非法经营，而在司法实务中是否最终认定通常看行为是否存在法条竞合（大多数情况下，非法经营均和其他罪名存在竞合情况），如果存在竞合的情况下，就从一重罪。

这一罪名的认定，非常依赖于侦察机关和检察机关的认定，人为因素影响非常大

真·空手套白狼。

先别急着做税务登记和税种核定，这样企业注销能简单很多。

只需要公安注销公章，工商注销营业执照。

---

讲真，没想好做啥业务，工商登记的时候，经营范围你是怎么写的？不能超范围经营，非法经营罪预定。但凡有点收入，金额很简单就到 5 年刑期的这一档。

显然没有啊，这玩意国家也不承认，如果你能够向司法机关证明，这些属于”财物“，那么也许能够向不当得利、诈骗罪等方向靠拢。可问题就是国家不承认这个东西，就像赌债一样，所以没有投诉渠道。能不能收回来，全看个人本事。

f-droid 可以添加自定义的存储库。

黄果树不推荐（特别是现在，应该会很冷），至于其他提到了，我没去过，苗寨网上搜一下差评，如果还没解毒，去了回来记得 at 我（我是看了一些负面评价后怂了没去）

体力好，推荐梵净山（当然啦，有钞能力也可以）

@jim9606 #14 那这个需求的本质其实是做一层隔离，而隔离的目的并不是为了安全，而是为了解耦。

解耦，这样的设计是具有积极意义的，并且在实际生产环境中也很常见。
安全，如果非要说这样兜一圈安全性有什么提升，应该就是自己做一些额外的校验工作，例如频率限制、限制来源、负载均衡，添加原后端请求不支持的安全参数等，但这样就不是一个简单的服务的包装了，这更接近于业务逻辑。涉及业务层一般就不太会有楼主希望的那种第三方或者比较具有通用性的统一包装服务了。

其实没差别啊。

如果用户侧持有某个 KEY，可以导致其访问某个业务。
现在你通过中转服务隐藏 KEY，用户侧直接访问这个中转服务，一样可以访问其业务。

本质上没多大区别呀。

鉴定可信终端不是依靠信息不对称实现的。

不考虑政策限制，不愿意付钱，那谁会提供这样白嫖的服务呢？

更何况这里面还有很大的政策限制，压根不允许搞这样的业务。

设使用月份为 M，
则，租赁费用 = 420*M
购买费用 = 120*M + 12W

如需满足购买费用 < 租赁费用，则 M 应该大于 400，即持有时间大于 400 个月（ 33.3 年）时，购买成本低于租赁成本。（如果租赁费用为 300 元 /月，则需要更长的时间，购买成本才会低于租赁）

但上述是纯理论计算，没有考虑产权因素、通货膨胀、买卖成本等，供参考。

小声地说，反正我是不会买车位的，再老的小区也都停的下，现在的新小区车位个人觉得只会越来越充足。

这种情况比较麻烦，docker 本身设计成无状态，就是为了随时用随时销毁的。

由于存在了未持久化的数据需要保留，建议将相关内容复制出来后，然后重建容器。

也就是#1 的第二种方案，至于#1 第一种.....嗯....dirty solution，可以是也可以，如果是抱着”又不是不能用“的想法，这种方案更简单。

因为没有版权啊。

比如张三的《张三之歌》，版权是腾讯的。
那网易铁定不能播放，但是李四翻唱的《张三之歌》就可以播放了。

什么？你说侵权？那是李四的事情，管我网易什么事情。大不了我下架就是，还有王五唱的《张三之歌》，实在不行还有群星演唱的版本，群星都不行了，还有佚名。

如果实时性比较高，支付时是比较难避免重复付款，因此需要设计对账、对冲。

即假设本地业务系统的支付流水在数据库中分别保存与不同支付渠道的支付流水号对应关系，在业务低谷期（如次日凌晨），检索当日所有所有支付流水对应的第三方支付流水，是否存在多笔支付成功的第三方对应一笔流水号，如果存在将时间靠后的做自动退款。如果真的毫秒级都时间相同就按自定义顺序退款（如先尝试退微信，后退支付宝）。

这是每日的对冲，每笔第三方支付成功回调时，也可以即刻检查本地的业务流水号是否已经被其他支付渠道标记支付成功，如果有就直接退款，当然这种方法对自身业务系统的并发设计能力较高，而第一种就简单一些，无脑收钱，次日对账，多了再退。

@zhoushiya #163，按照你说的进去，是截图这样的界面，似乎并没有关于”计算方式“的选项，是因为企业报税的关系嘛

https://i.loli.net/2021/03/02/D9vXVUjuSJdnLym.png

@zhoushiya #96 有截图嘛，我在 APP 和网页端都没有找到相关的选择“综合计算”

补 3500 块钱