跟微软连线不稳定的时候，开启自动保存会相当难受。但是只要你别做骚操作，两周之内是不会丢东西的。

@pandazhong123 #72 如果是面向传统前端的标准 URL ，或者 RESTful ，或者是公开接口，那么应当是 book-detail 。URL 在部分场景（比如 Windows IIS 当服务器），是不区分大小写的。下划线则是在部分字体或者 UI 下，容易看不见。如果仅面向当前项目的前端，那就看团队习惯，对于全 Java 系开发来说，bookDetail 更舒适。

@lambdaq #65 会跟新增 「 user 」 的 「 delete 」 冲突。

关于 RESTful API 如何表示领域行为方法，这个我也是抄别人的，就直接贴链接了。
原文（也是翻译老外的）链接： https://mp.weixin.qq.com/s/251ql2WhDi-InUgVtIQ6_Q
我看的是转发： https://blog.didispace.com/use-ddd-design-rest-api/
请注意，这也是违反 RESTful 的，需要有全局约定才能这么做。他并不存在冲突，因为 PUT /resources/{id}/action 是专有的 URI （原本的 PUT 因为是修改指定资源，其 URL 形式必定是 PUT /resources-level1/{id}/resources-level2/{id}的形式。）

关于 REST 的参考： https://restfulapi.net/resource-naming/

关于单复数的部分，需要纠正，REST 接口，资源必须定义成复数，因为单数名词有特殊含义，他是定义可选的前置分组的。当然，这是个认为约定，不是强制规定。如果约定好，全部单数也不是问题。

再纠正一下 14 楼的回复。「如果是一般动作，那就是 POST /user/{id}/%动词%，比如 POST /user/{id}/disable 。」是错误的。应改为「如果是一般动作，那就是 PUT /users/{id}/%动词%，比如 PUT /users/{id}/disable 。」因为这个动作，是对当前资源的修改，不是新增资源。

@theqiang #28 按下 SHIFT+ENTER 换行，结果直接提交回复了，下面一楼才是完整回复。但是好多人好像只看到我这个半回复，没看下面的完整回复。

@hidemyself #29
DELETE /user?phone=xxx 跟「根据用户手机号查询用户列表」，是一样的套路。

@george2077 #44 /user/add /user/delete 并不符合 RESTful API 的设计原则。RESTful API 的基准原则就是，URL 仅表示资源路径故只能是名词或者等效于名词的东西，GET/POST/PUT/PATCH/DELETE 这几个 method 才能表示动作。所以只能是 POST /user ，DELETE/user 。（单复数我忘了，好像应该是复数形式。）如果你用/user/add ，最经典的问题就是 @Pastsong #27 提到的 /user/{id}冲突。但他的 /user:add 这样也不对。

严格 RESTful API 有一个经典缺点，就是 GET/POST/PUT/PATCH/DELETE 动作不够，无法表示其他方法。当你采用领域模型来设计接口的时候，这个确定会更突出，因为领域模型在增删该查之外会有大量的其他行为方法。这个在后面单独说。

@lambdaq #50 根据 ID 批量删除：DELETE /user?id=xx,xx,xx 。根据条件（批量）删除：DELETE /user?condition=xxx

官网申请卡只能填英文地址，没法附加中文国内地址，信件转到国内之后，大概率被邮政直接丢弃，收到的可能性很小。

Mysql 你分不了区的，这货要求分区键必须在所有唯一索引之中，意味着你必须要改主键，还是改成复合主键。

两个都不对。/user/add 是画蛇添足。/add/user 是分组错误。

RESTful 风格
添加：POST /user 。删除 DELETE /user 或者 DELETE /user/{id}。如果是一般动作，那就是 POST /user/{id}/%动词%
，比如 POST /user/{id}/disable 。
仅 POST 风格
添加：/addUser ，或者/user/addUser 。删除：/deleteUser ，或者/user/deleteUser 。对于后面那个，/user 只是用来分组的，不参与接口命名。

RESTful 风格添加：POST /user ，删除 DELETE /user 或者 DELETE /user/{id}。

如果异步方法本身未返回 Feture ，并且你还不能改它的话，放弃吧，无解。你不能期待一个吃草的狼。

如果你的不能改，只是因为框架的限制，不能改方法的返回类型，但可以改方法体的话（ 我猜你在用 Spring 的 @async ），最好的解决方案，还是换异步调用的方式，用 JDK 自带的就行，也费不了多少代码。
CompletableFuture.runAsync(() ->{
// 需要异步执行的东西，但这个方法内部，要是同步的，不要转向调用那个写好的异步方法
}).XXX// 这里既有不阻塞的，也有阻塞的，名字忘了，自己找一下。

极端情况下，连 JDK 自带的都用不了，比如你上面那个方法体中，还要再调用其他不返回 Feture 的异步方法，那就只能回滚最传统的方式了。弄个在第三方位置的标志数据，异步方法执行完成时修改标志，主方法调用异步方法后，轮询这个标志数据。但是这也有个前提，你得能改异步方法得执行体，不然就又回到第一段了。

啥电视都不能当显示器用，都有一个致命弱点：（同尺寸相比）便宜——货不好

怎么总有人把合伙人、股权，这种必定要出钱，不一定能拿到收益的高风险投资角色，当作员工福利呢。

真正的文人，可都是对文字狱十分敏感的家伙，早几年就陆续封笔了。不那么敏感的，也被三年前的阅文事件搞飞了。真像看，还是找些存量老小说看吧，正好也不怕烂尾。

@zx9481 #10 整个日志，都没有 error 级别的，看着就是 Redis 连上那一刻，服务自行结束了。这个不是无法启动，是启动后自行结束。日志上能看出，这是有 Web 服务器 Undertow 的，基本可以排除启动类不是 Web 启动类这个原因。那么剩下的，有很大的概率，各组件的集成问题。初始配置的问题，还是要找这个项目的老程序员给找找错误原因，外人很难找出来原因。

啥错也没有，这就是跑起来，执行完，自己退出了。把你的 BootStrap 类贴出来看看，估计用错方式了。

这日志配色看得是真头疼

ARM 性能上不去（或者说能效比涨得比频率快），X86 待机功耗下不来。

第一，如果真按照楼主说得这么卡，基本上说明公司是想要牲口的，那就真没必要去。
第二，既然没必要去了，而且还没去，那干嘛要委屈自己，这妥妥的招聘歧视行为，一举报一个准。

单引号不转移，双引号转移，这确实不是 BUG ，也确实是 Shell 、Perl 、Javascript 等的传统用法。但这种容易引起混淆的用法，不就是大坑吗。

一个月后发现，自动更新仍在继续运行，编辑注册表禁用自动更新的方式，失效了。也特么沙雕了，既然微软都干了补丁里面喂屎的行为，自然也会干忽略「禁用自动更新」的行为。