羊岛名物也就是奶粉、蜂蜜什么的吧

我都是只用 mybatis ，从来不用 plus 。个人认为楼主也可以抛弃 mybatis plus ，手写 sql 它不香吗？

业务代码也就是 crud ，什么语言都能做，但总体来讲 Java 生态最完善，也就是能用的轮子最多，也最容易找到合适的轮子。有了轮子，车什么的不就加张沙发的事嘛。

楼主你老婆用 Java 怕是能无师自通

@dcoder 滥用关系型数据库确实存在，但不能因此否认关系型数据库的特定用途。你说的当成 KV store 使用的这种现象，就是典型的滥用关系型数据库。

另外，关系型数据库可不是什么弱鸡抽象工具。

不要回滚，用备份恢复数据到新表，然后根据 ID 从新表更新数据到原表即可。这样损失最小。

路由最基本的规则就是掩码越大优先级越高，0.0.0.0/1 dev vpn 这条路由是优先级最低的。
你把本机路由表打出来看看就知道了。

1 台撑不住的时候，自然就要做负载均衡了。f5 这种硬件设备就是干这个的。当然通过 dns 指向多个地址也是一种负载均衡的方案，只不过这个方案你要有多个公网 IP 可以分配给多个 nginx 主机。

很简单，你想一下你依赖的第三方包，譬如 redis 所需要的 ip/port 等参数是怎么配置的就明白了。

楼主你拿过 S 了呀！这次拿 B 不是你领导的基操吗，你自己换位思考一下，想不明白年后估计换个坑位比较好。

别纠结买什么车了，也不要分期，买辆买得起的国产车暂时代步。然后等着开陪嫁的豪车就行了。

@ZinWUT 我估计你怼不过。因为对方只需要把分页的需求拿出来，你就傻眼了。我就不信订单列表会没有分页。

第一个接口没什么好说的，第二个接口独立出来的目的是分页加载数据，按书籍为维度的订单，想必上万甚至几十万几百万也不稀奇。你能一次加载？？？真这样干，怕是要被用户骂死，什么垃圾玩意，打都打不开。第三个接口我就懒得说了，列表都不能一次加载，何况详情。。。。。。列表+详情，怕是 1 本书有几百个订单，系统就要崩溃了。

这个要看具体情况的，一般来说书籍信息不包含订单信息。如果书籍信息只有一个地方使用且需要包含订单列表信息，且订单列表不需要分页的话，这两个接口合并到一起也说得过去。但直接把每个订单的详细信息一次性给你，你有地方显示？不需要点击订单列表里面的订单再跳转订单详情页面？谁会每次都去挨个查看订单详情？你前端就不嫌数据太多接口太慢？？？

所以，正常情况下，分 3 个接口一点问题都没有。

最早的 unix 是区分大小写的，但你看后来 linux 就不区分，基于 freebsd 的 macOS 也算是正宗 unix 了，但它也不区分大小写。这说明啥，说明区分大小写坑人啊。

可以这样把变量拼进字符串：string cmd = $"Remove-MobileDevice -Identity 'androidc287586998' -Confirm:{变量}";

@gadfly3173 还有背景

必须是《银河英雄传说》。


其实《太空堡垒》更好看，但叙事宏大可能就挨不着