{ "100":{ "id":100 "title":"xxx" }, "105":{ "id":105 "title":"sss" } }这种大多数情况下都不适合用来作为一个集合的数据结构。一般情况下，集合中的元素的 id 是无意义的，也没人关心它的值。这和 k/v 结构中的 key 不同，key 是约定的，是有意义的。

如果前端需要知道 100 这个 key 对应的 value，那么楼主的数据结构是合适的，如果前端只是列表显示，[{ "id":100 "title":"xxx" },{ "id":105 "title":"sss" }]这种结构才是合适的。

有键盘印，但不明显。上次换键盘的时候我提出更换屏幕，但没给换

@li353360 应该是“大博”

@pkwenda 同遗忘，不百度根本写不来了……注释真香

可以安装官方远程桌面

楼主不要在意，这种趾高气扬的我见多了，也没比我强到哪里去。

如果我遇到这样的面试官，我就坦承自己懂得不多，所知道的那么一点东西不值一提，然后反问对方他是怎么做的。如果对方能够说得头头是道，那么一方面也能学到点知识，另一方面，人家在毕竟你面前装了好大一个 B，可能会觉得你谦虚好学，要了你也不一定。如果对方张口结舌，那就比较僵硬了……哈哈哈，对方一定是吃了苍蝇般难受，你就可以愉快地结束面试回家了。

是的，只要你能把所有代码都写对地方就行。

正常的操作逻辑：在 A 上面打包成 jar 或者 war，然后上传到 B 发布。

你非要通过 A 控制 B 去 pull 源代码打包发布也不是做不到，但会比较麻烦就是了。

本来也是和楼主一样的计划，然而因为疫情，也只好先维持维持了。

@keelii
> 前端代码中本质上讲 HTLML/CSS 都是配置文件，而且是「快销」的配置文件。它不需要抽象，只有 JS 有逻辑，需要抽象。但是前端不得不把配置文件和程序的代码混合在一起，而且在这中间摇摆不定，最终使得代码没有条理。

我个人理解，前端的 3 个组成：UI(控件)、数据和交互事件，组成了 MVVM 里面的 View，应该由 HTML+CSS 来定义，这里面不应该包含任何的逻辑。ViewModel 负责数据和控件的绑定，处理交互事件，如果需要加载 /保存数据，则回调 /调用 Model 里面的相应方法。ViewModel 和 Model 只有 JS 代码，不应该有任何的 HTML 和 CSS 代码。

MVVM 模式本身就是一种抽象和封装，但似乎很少有人能够理解 MVVM 模式，大多数程序员只会套用框架。其实交互逻辑有时候也挺复杂的，其复杂程度并不下于后端的复杂的业务逻辑。如果不能适度抽象和封装，这代码想必是 bug 百出且难以维护的。面对这种挑战，前后端其实也没什么不同。后端相对来说会比较成熟，所以前端在遇到挑战和困难的时候，也不妨看看后端是如何解决的。

@DOLLOR 你说的很对，这就是过犹不及的道理。做什么都应该掌握一个合适的度，在工程上面尤其如此。

用 select 的结果集替代 values 的内容，一般用于倒腾数据、生成临时表记录和使用模板数据来生成记录。

我认为前端主要的问题是不懂何为抽象，何为封装，更不懂什么叫做结构。结果就是代码臃肿、混乱，难以阅读和维护。当然后端同样，但比前端稍好一些。

@qloog 就是语法要求更严谨一些，原来 5.7 上没问题的 sql，8 上面可能会报错。跑一遍单元测试就知道有没有问题了，有问题也很容易改。

去年就升级为 8 了，然后有一点小坑，处理完就好了。

这个解耦没多少意义啊，而且平白地增加了复杂度。再说，日志是允许丢的数据，没必要和数据完整性死磕呀。
@wangking

耳塞洗不坏，晾干还能用。没有连耳机一起洗就成，哈哈哈