装修师傅还在羡慕你坐在办公室吹着空调就把钱给挣了，还比他多！回家又和儿子说要好好念书考个好大学，不要像他没上大学只能赚点辛苦钱。

为啥电视机都是一个样子
为啥冰箱都是那几个样子
为啥 xxx 的样子都大同小异……

相同的内在的功能决定了外在的样式只有一个最优解，想要玩花活就得付出更高的代价。但这个世界上没多少人会愿意为你的花活付钱，所以大家都是按着最优解来做的，只能在细节上稍作改变。

先说前端，虽然是假权限，但也是需要根据用户权限来显示 /隐藏对应的操作按钮，或者更进一步显示 /隐藏相关组件。

后端既然楼主要求动态，那么鉴权就不能通过注解来实现了。你可以通过拦截器或者干脆在网关上面实现鉴权。思路无非就是通过解析 token 来获取用户信息，然后根据用户信息来鉴权。

不用管它，对于锂电池来说，只有过度放电才会损伤容量。但也不要一直充电从来不放电，我司有台笔记本一直插着电用了 2 年多，有一天电源拔掉就开不起来了，电池彻底废掉了。

突然发现手机屏幕小的好处，就是支付宝的广告在下面完全看不到。不看这个帖子我都不知道支付宝有广告，哇哈哈哈哈哈哈

别问，问就是：是。你挤占了别人的生存空间你造吗……手动狗头保命

好好商量，承诺后面交接尽量配合，好聚好散。不然人家拖你 1 个月是合理合法的。

{ "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 百出且难以维护的。面对这种挑战，前后端其实也没什么不同。后端相对来说会比较成熟，所以前端在遇到挑战和困难的时候，也不妨看看后端是如何解决的。