人老了容易生大病，家里老人三线城市住院一个月动不动就 7000+，医保报销 70%。2022 年 65 岁以上人口达到 14.2%，60 岁以上 18.9%。国际定义 65 岁以上人口到 14%是老龄化社会。预估到 2040 年，60 岁以上人口达 30%+。医保开销更大

@drupal 我那个只是 Demo ，我公司在用这种模式。像若依那种才是主流的方案吧。比较这么系统都是这样设计的，有它存在的意义。我们公司一开始也是用主流的方式，后来嫌步骤繁琐，就简化了。

@ikas 原来如此，了解。我公司做的都是自家的产品，用户比较小。菜单配置 url 这些，后端管理的一段时间，后来嫌麻烦，新项目后端都不管理，前端也不配置了。

@drupal
JDK8 版本的，master 分支是 JDK17 版本，没有维护了，代码比较旧。JDK8 版本是从 JDK17 版本转过来的，然后重构的项目，简化了逻辑。
https://gitee.com/LuPangJieDeng/base23-spring-cloud/tree/JDK-8

@ikas
菜单表是怎么设计的？存放什么数据？

前后端分离后，按钮,菜单这些数据感觉就没用了。后台完全用不上。菜单和资源的关联关系，也只有前端自己使用，如果存数据库的话，每次登录，前端都得到后台拉一遍这些数据。同时这些数据都是代码相关的数据，值固定不能改，存数据库感觉没有意义了。我现在的项目，这些菜单数据、菜单相关的资源，菜单和菜单资源的关联关系全部丢给前端自己写死在代码里面了。后台只关系用户拥有的角色、角色拥有的接口权限。其他一律不管。至于个人拥有哪些菜单、菜单资源，后台给个 text 字段，前端自己随意传数据到数据库持久化。

@drupal 我已经搭建一套权限系统了，使用 SpringBoot 3.0.2/2.7 + SpringCloude Gateway ，JDK17 和 JDK8 的版本都有。前后端都做好了。也已经放到 github 了开源了。创建用户，单点登陆 / 退出登陆、前端动态路由、用户授予角色，角色授予权限，后台 API 鉴权等都做好了。目前还没写文档。想看看别人怎么做的，目前见得最多得是类似若依那一套经典权限系统设计。

关于技术选型：使用 JDK21 只能在一些生命周期短小项目跑。新出的 JDK 都不稳定，需要 2-3 年时间才能稳定，没啥兴趣。现在 JDK17 也只是小规模试用。我尝试新项目使用 JDK17 ，结果偶尔会遇到一些三方工具包，或三方工具不支持，只支持到 JDK8 ，每次遇到这种问题都得浪费我 1-2 个小时去处理。使用 JDK17 让我感觉到自己在浪费青春。旁边的 JDK8 沉淀了大量成熟的开源工具，很多都没支持 JDK17 。对于上班搬砖的人来说，使用 jdk8 是最舒服。另外 SpringBoot 3.1 也是半成品，用过 Springboot 3.1.2 ，结果日志打印提示，一些 spring 自家的组件都不支持 3.1.2 ，还建议我用上一个版本的 springboot ，然后我又退回 springboot3.0.2 了

@ikas 关于 Resource-Based Access Control 模式，各种博客和技术文章的说法不一样，我曾经困惑了很久，和朋友研究了一个星期，直到看见了 stack overflow 的回答：
https://stackoverflow.com/questions/18435219/resource-based-access-control-vs-role-based-access-control

Resource-Based Access Control 这个名词出自于一个国外程序员写的一篇博客中（ stackoverflow 的问题给出了原文地址），这个程序员自己定义的一个新名词，而且只有他自己一个人在用，不是通用模型。我看了那篇博客原文，Resource-Based Access Control 所定义的内容，就是 RBAC(role-based-access-control)的具体实现。而 RBAC(role-based-access-control)是 NIST 定义的标准，是一个理论模型。中文资料中关于 Resource-Based Access Control 的定义要么是翻译了原文，要么是在原文基础上二次修改。英文资料已经找不到关于 Resource-Based Access Control 的定义了，博客原文都打不开了。虽然我们常用的权限系统的设计和那篇博客的所描述的内容大同小异，但我不建议使用 Resource-Based Access Control 这个词，这个词和 RBAC 放一起容易混淆，而且找不到关于这个名词的标准定义。

常用的关于权限系统的设计模型有两个（维基百科英文版给出了很详细的描述）
ACL(Access control list)：用户、权限。用户名下直接挂权限，优点：灵活。缺点：要给每个用户都设置权限，繁琐。
RBAC：用户、角色、权限。用户名下挂角色，角色名下挂权限。优点：简化了给用户设置权限的步骤，满足的大部分业务场景。缺点：灵活性稍微低一点

现在业务系统几乎都是基于 RBAC 设计权限。除非客户强制提需求：“我就不想新增一个角色，就想单独改一个人的权限”，特殊情况下才用 ACL 。

前后端分离的情况下，权限管理被分割成了两部分：
1. UI 界面组件的显示权限（也称为菜单权限、按钮权限、目录权限等）
2. 服务器 API 的访问权限（也称为资源权限 resource ）

当给一个用户授权某个功能的使用权时，至少需要授予两个权限：UI 组件权限、API 访问权限（这个组件所访问的 api ）

从理论模型分析：功能 = UI 权限 + API 权限

从用户的角度看授权，进一步被简化成了：功能 = 权限

@charming61 在深圳面试过，95%先问八股文，里里外外问一遍。八股文过关后，再问项目（有些面试官可能不问项目）

你说的这种情况：“发现其实人生高度也就这样，换个地方也改变不了太多，感觉有种虚无感。就是这辈子感觉就是在为房车奋斗着，没什么存在的意义。大学时期写代码是真的快乐，但一开始工作就是一种一行代码都不想写，每天过着带薪摸鱼的日子”。换到国内工作，这种无意义感更强烈。我干了 5 年 Java 开发，国内的互联网没什么新鲜事了，越来越感觉程序员像制造业流水线。要是考虑开公司的话，有这实力，为啥不尝试在国外开？在钱多的地方挣钱不是更容易？回国内只会更艰难。考研的话，目的是为啥呢？做科研，还是做公务员？现在国内已经没啥新兴领域可开发了，剩下的前沿科技都是硬骨头，成本高，产出少。

个人看法：
产品 1：”通过 AI 生成 xxx 或做某事来提高开发效率，可以节省成本“，未来 5 年内做不到，可能再过 10 年都很难做到。AI 可以提高效率，但现阶段需要投入巨大的成本，普通个人和公司都无法承受。可以参考下历史：瓦特蒸汽机 1769 年发明，英国到 1830 年代之后才将蒸汽机投入生产，美国要到 1860 年代之后。电力理论在 1880 之前就已经完善了，美国的生产力从 1888 到 1907 依旧增长缓慢。计算机在 1950 年左右发明，到 1990 年才开始促进生产力的发展。AI 在上世纪开始研究，到 2022 年 12 月份才出现了 ChatGPT3.5 。

产品 2：ChatGPT 套壳产品。缺点：1. 不稳定，openAI 各种限制中国地区使用，麻烦的很。2. 成本高，租国外服务器的钱会转移到消费者头上。消费者不会这额外的钱。3. 国外已经有这样的产品了，做得还不错，而且他们成本更低，比如：POE 。4. 在国内搞这个，可以被举报成违法获利，让后就被没收违法所得。

产品 3：金融记账类产品，所有支付软件都自带，无需人工记账，个人用不上。对公司而言，对数据保密要求很高，他们宁愿用 excel ，甚至不希望把账目写得太清晰。成非认识的老板乐意投资你本人，否则无市场。

产品 4：AI 绘画，有点意思，看起来很好玩！