不可能是连接池满导致查询满 服务器都重启了。正常来说连接肯定都是释放的。我怀疑是内部网络问题

我一个后端 现在已经给公司开发一套前端组件库了

我就很好奇 买这种个人便宜服务器的，带宽固定 1M 。 这玩意能干嘛，放个博客？ 代码仓库？ 服务器到期了续费变回原价，你肯定是不会续费了。还得迁移 不够折腾的

SK2 碧欧泉 可以试试

时间戳啊 时间戳肯定没有时差的问题。

千万别听楼上用 vscode 。
你只需 选择 ASP.NET 和 Web 就行了

扣减做成异步，本身就无法实时同步，肯定会有数据对不上的情况。当你选择异步处理业务的时候肯定做做取舍。
一般这种情况，前端请求服务后直接做加减，障眼法。
要不就是轮询，等待异步业务处理完成

看你的方向啊，只搞后端不需要学习 html+js 。 如果你要搞网站想要漂亮的 UI 那你就得学习 html+css+js 。

java 给 c#擦鞋都不配

游戏开发 技术是最不重要的

说直接用 http code 代替应用返回的状态 肯定又是一堆被 restful 洗脑的教徒

接触更多的业务场景，先写一半能达到 最小可用，然后在优化重构。

linux 桌面系统拿什么和 Windows 比。 讨论 linux 非得黑一下 Windows ？也是够了

正如 11L 说的那样，你这样的封装 没有啥意义。
ORM 可以做到
dbContext.XXXTable.where(x=>x.age>=18 && x.sex =1).group(x=>x.school).sum(x=>x. score)
这样的查询你如何封装呢？按照目前的做法 ，无非就是在 DAO 层 增加一个与之对应的接口。
如果想做到业务查询能映射到数据库或者其他的数据源或者 ORM，你就得引入规约模式，还得需要吧规约转换成其他 library 写法。还得提供每个不同的 library 提供转换 provider 。
既然引入了规约是不是还得包装一个 unit of work
你做到这里时，你回发现你所做的这一切 ORM 都给你实现好了。

要做到业务查询和 ORM 之类的库解耦，这个绝对考验设计能力，绝对不是你这样简单的封装就解决的问题

几千个用户 用啥设计啊 数据库 order by

下单减库存 和支付减库存做成配置项就可以了。减库存这个也不是啥难点吧。。。。

业务代码很难进行单元测试的。
数据库没法进行测试,引入 InMemory DB 对数据库达不到测试的要求。
如果要介入数据库还得写插入和清库的代码。
第三方依赖也是一个问题。
到最后你会发现，写业务代码一个小时，单元测试得写上一天

@waibunleung 这样的封装 会导致失去 ORM 很多的特性,而且会导致 DAO 层越来越臃肿 出现很多 FindByXX 之类的 func

ORM 和 DAO 是不冲突的。Repository 和 DAO 不是一个概念 。
DAO 是单纯的对数据库进行增删改查的一些操作和特殊的业务逻辑。
一个好的 ORM 基本就代替了 DAO 层 90%的作用。可以看看 DotNet EntityFramework Core ORM 基本没有比他还好用的
如果你的项目涉及到多种数据源需要提供给 Service 这里可以引入 Repository 的概念
使用了 ORM 也没有必要在对 ORM 进行一层封装，这种封装我认为是脱裤子放屁。