中文字段挺好用的，一目了然，在领域专业较强起名困难的情况下是一个很不错的选择

JS 分号可以不写，你自己处理好特殊情况就可以

Python:
names = ["name1", "name2", "name3", "name4", "name5"]


def loopSelected():
for name in names:
print(name)

JS:
let names = ["name1", "name2", "name3", "name4", "name5"]

function loopSelected() {
for (let name of names) {
console.log(name);
}
}
或者
let names = ["name1", "name2", "name3", "name4", "name5"]

function loopSelected() {
names.forEach(name => {
console.log(name)
});
}

并没有麻烦到哪里去

@Macv1994 那按照业务逻辑应该是需要时间倒序的，group by 排序我记得是没有保证的，查询非 group by 和非聚合字段也不符合 SQL 标准。
如果用的 MySQL8 可以用开窗函数，如果是 5.7 那就子查询按照对话双方来分组查询最新时间。
因为这里是对话，应该需要按照 receiver 和 sender 两个字段分组吧。

为什么需要 group by ，一个发送人只显示一条吗？能明确一下规则么

同意楼上，看现象连 nginx 的报错页面都没刷出来，说明是连接 nginx 的问题

@so898 极端化例子没有意义。用用 Google 、玩玩塞尔达和持有枪械是一个性质的事情吗？我想在正规国行平台玩塞尔达，想在 iPhone 上用自带商店看看书买点电影，有严重到“精致利己主义者”这个层面吗？

@phpnote Apple 能进来：指的是按法律法规和正规流程申请开通的 iTunes Store 和 iBook Store 业务没开几天就被无正当公开理由强行关闭吗？

这个问题有一段时间了，GitHub 有讨论
https://github.com/vueComponent/ant-design-vue/issues/4467
https://github.com/vueComponent/ant-design-vue/issues/3191

iCloud 相册共享，挺好用的

直接使用 SQL 不行吗？这个需求数据库直接就可以解决吧，何必写代码

这个要看你的部署机制。如果是分开部署，想让前端路由生效，nginx 本来就要进行设置，肯定不会走后端。如果是先后端解析再把页面当作模板返回，那就是后端路由为主了，这种情况下需要后端的 controller 设置一下通配符，把未定义路由统一交给前端解析。

看了下铃木的网站，element 做起来没问题，功能上内置组件都覆盖了，但是样式要大量定制。element 提供主题定制的功能，自己再改改 css，问题也不大。你自己写也行，但是自己写组件要自己实现操作逻辑，这些东西组件库都帮你做了，从快速出货角度考虑没这个必要。
看你仿的页面感觉主要是你前端不熟悉，尤其是布局和 css 。你还是先用内置组件把页面拼出来，再慢慢调整样式吧。

这个是 Response 吧。如果你用的是 ajax，直接浏览器就能看。如果你知道自己需要获取请求属性，RequestEntity 或者 HttpServletRequest 都有 api 能看。

这个不存储，是指单个实例不存储，还是整个系统就不在数据库存储用户认证系统？如果是前者，你不手动保存自然不会存储。如果是后者，那么自定义一下 User model，一个认证 Backend，自己实现一下鉴权方法

如果没有特殊需求，不需要保存前一个被点击的条目吧。只需要在树状组件维护一个叫 selected 的 state，用于保存被选中 layout 的 ID 。在循环渲染中，如果该 layout 被选中，传一个 active 为 true 的 prop，用于标记高亮就可以了。当进行点击时，触发一个 change 事件，把点击的 layout ID 作为参数传递，在树状组件处修改 selected 即可。

以前做过类似的加的是时间，实现比较简单

我习惯用单独接口，每次打开页面请求一下。单独的接口合理一点，因为不一定能保证当前用户和登录时返回的信息一致。

你的思路可以实现，自定义 manager 、queryset 和 model，覆盖 crud 方法就可以。或者用 signal 实现。注意自带的批量不会触发这些方法，所以要单独处理。

不过我觉得权限放在 orm 这层可能不是个好主意，以后修改维护都不太方便，orm 应该只关注查询，加太多功能就太臃肿了。为什么不能放在视图层？这个是最自然的解决方案，根据请求和 user 直接判断，也好维护。