ContiNew Admin

切换日光/暗黑模式

常见问题 ​

温馨提示

以下常见问题仍无法解决你的疑惑，可尝试 进群 与群内各位大佬交流沟通。

其他 ​

提问的智慧 🔥🔥🔥 ​

温馨提示

如果您之前在技术类交流群提问时经常没有得到有效反馈，建议先百度搜索或链接直达阅读 《提问的智慧》（如果你做惯了“甲方领导”，请必读！）

维护团队成员都是在各自 业余时间 维护（fā diàn） 开源 项目，有单独全职工作，也有各自生活节奏，所以我们提前告知您：

  1. 如果您遇到问题，请先依次排查确认：查看 dev 分支最新代码是否存在相同问题 -> 阅读使用指南 -> 查找常见问题 -> 根据报错信息（自行翻译英文）百度或 Google 一下 -> 搜索是否有其他人提交过类似的 Issue -> 阅读源码并在 IDE 中进行断点调试 -> 提交 Issue 及群内交流
  2. 欢迎您在 Issue 中复现存在的问题，Issue 我们必然响应，并且我们非常欢迎您提个 PR 来修复它
  3. 如果您加入了交流群，可以考虑在交流群内与其他用户大佬交流。维护团队成员视个人意愿及空闲时间解答 框架基础使用问题，谢绝技术问题，谢绝微信私信提问
  4. 项目在持续迭代中，此刻调研的您如果觉得它无法满足自身需求，也没有什么亮点，那只说明项目与您的需求不太契合，且仍需要迭代，请口下留情转身调研其他同类框架
  5. 请勿把维护团队当 “许愿池的王八”，如果你的需求场景仅仅是你的业务，请免开尊口
  6. 不接受频繁 “催更”，需求墙里列的后续计划 90% 可能性会做，无非时间精力影响，计划会靠前或靠后而已。所以敬请关注需求墙和群动态

项目能商用吗？ ​

项目协议是否可商用
ContiNew AdminApache-2.0 开源许可协议可开发商业应用
ContiNew StarterLGPL-3.0 开源许可协议通过 Maven/Gradle 等依赖方式开发商业应用

关于 ContiNew Starter 采用 LGPL-3.0 开源协议说明

很多人争议 ContiNew Starter 为什么采用了 LGPL-3.0 开源许可协议？其实这个开源协议本身没有任何问题，出发点就是希望能够汇集更多人的智慧，使通用的东西更加通用。但总有人看惯了 Apache 2.0 和 MIT 之后，下意识就认为这不可商用，这里统一说明一下：

从 ContiNew Admin v2.1.0 版本开始，我们调整了总体设计，抽取并封装后端基础组件及各框架通用集成配置 到 ContiNew Starter 项目。Admin 项目被设计为一个解决方案框架，提供通用应用和方案，而 Starter 项目则是被设计为一个应用脚手架，且发布至了 Maven 中央仓库，这意味着你可以在任意项目中直接引入所需依赖来使用这些配置。即使你不用 Admin 项目，你依然可以直接选择这些 Starter 来让你的 Spring Boot 程序开发变得更 easy！

Starter 的优势：

  1. 易于迁移： 我们选择一个程序框架的原因就是希望减少重复功能开发，实际上框架带来的不仅仅是成品功能，还有成品的基础配置。你要开始一个 Spring Boot 项目开发，你不需要配置 JSON、API 接口文档、跨域、线程池等配置吗？如果这些配置代码全都在 Admin 里，没有 Starter，那你需要从 Admin 里复制很多的配置到新项目，或者说你要从程序框架中删除很多的配置代码。你能处理好，处理完整吗？你不累吗？我作为使用者之一，我感觉累。
  2. 易于扩展： 我们针对于 Starter 的开发目标就是通用且基础，不含业务逻辑，在设计和开发某个 starter 模块时，已尽可能开放了更多的“口子”可以进行重写或覆盖，你不妨看看代码。且未来在持续的重构中会继续优化完善，开放更多的“口子”，适配更多的可能，这恰恰需要更多人的智慧。

很多人担心要改代码怎么办？ Starter 是一系列组件，如果“口子”不够大，你可以反馈一下我们一起讨论完善，发布个版本很快的。如果不满足你需求，要完全重构，这种场景你完全可以不引入某个 Starter，自己去编写一个自己内部的 Starter，亦或者关闭某个 Starter 的某些配置，改为采用自己的。（LGPL 涉及到的二次开发并不包含重写覆盖配置 @Bean、@Override，这是面向对象和 IOC 的魅力，和开源协议并不冲突，不要过于担忧协议范围）你换个参照物想一下，你把它当成 Hutool 工具库，Hutool 里有的工具方法你直接用，Hutool 里没有的你不也需要自己写或基于 Hutool 里的方法继续封装工具类吗？这难道也要担心涉及侵权吗？当然了，如果是改改包名或简单改动就发布为了另一个项目，我觉得懂点法律身怀正气的你都知道这没什么必要。

  1. 易于上手： 抽离了那些基础配置，Admin 就是一个纯粹的业务解决方案项目，大多数人需要的就是这么纯粹的内容。即使你是个新手，想要上手这个项目，你不需要关注那么多的其他配置了，甚至说它们对初学者是无关紧要的，这大大降低了你的上手/学习及改造成本。
  2. 易于升级： 对于一些配置优化和完善，升级只需要改改 Starter 版本号，不需要你再照着最新版疯狂复制代码，减少你出错的概率，提升你升级的效率。
  3. ...

总之，我们希望更多人多多反馈，一起完善。有技术的捧个技术场，有人的捧个人场，有钱的捧个钱场。

项目能二开开源吗？ ​

非常欢迎在遵守对应项目开源协议的基础上进行二次开发开源，扩展生态系统，如方便欢迎在 生态系统 中登记，给有需要的人更多的选择。

接不接定制开发？ ​

作者仅在业余时间维护开源项目，有单独全职工作，不接定制开发。如有需要，可协助各位老板在交流群内发送广告。Coder help coder.

作者是全栈吗？ ​

Creator 是 Java 后端开发，不擅长前端开发（欢迎有意的前端同学参与 PR 开发），所以很多时候，你会看到后端会相对频繁更新。但在提供解决方案时，会尽力通过迭代方式逐步完善前端细节，且拥有一双发现“美”的眼睛。

Creator 虽不擅长前端，但对前端开发仍坚持追寻 “持续迭代优化，持续提供开箱即用，舒适的开发体验。” 的 slogan。

ContiNew Admin ​

常见差评回复 🔥🔥🔥 ​

“不是所有的鱼生活在同一片海里”

“道不同，不相为谋”

  • 烂大街了，这类项目这么多，老是开发有什么用？看起来也没什么亮点啊。

  • 为什么要用你这个，还要增加学习成本？为什么不直接用 Xxx？

    本项目简介中的项目来源有做详细说明，正式立项于作者当时工作需要，工作自用为主，开源的核心目的是共建和持续完善，无心推广和参与竞争，如果恰好能帮到更多人，帮助其梳理一个基础规范模板，也能满足作者成就感。

    作者热衷细节重构，有代码洁癖，所以项目重点始终在于代码质量（主要后端、次要前端）和解决方案细节完成度，欢迎更多 “代码洁癖”、“志同道合者” 多多 “批判”。

    为了降低项目上手难度和后期学习成本，在迭代过程中，我们也做了大量的删减和重构，ContiNew Starter 的产生缘由之一也是为了降低学习成本，这是个持续的优化过程，也需要更多志同道合的社区伙伴给出意见和建议。

  • 自己写一个也很快，简单的很，看别人代码头晕

    对于认为自己写一个也很快且简单的很，本人不予置评。

    但自己写一个，确实是挺好的，如果你有高频的需求，自己封装是个好的选择，这就是本项目来源中提到的沉淀。如果你写不出来，要参考一下，上一个回答里也提到了，如果恰好能帮到更多人，帮助其梳理一个基础规范模板，那也是一件好事。

    本项目持续优化代码规范和逻辑细节，如果能改善更多开发者的基础素养，这无疑是好事。

    当然了，吃了饭砸锅的事，也不少见，但它们是少数。

  • 初级程序员都爱写后台管理框架，因为简单，收获一些 star，到时候可以在简历里吹嘘。

    也许你真的是个大牛天天研究算法不下“基层”无此需求，也许是你的标准太低认定写一个中后台管理框架简单。

    作者在公司里也从没透露过所用的 ContiNew 框架是自己主导编写的，更遑论简历中。让领导和同事更多关注到自己，把自己“捧杀”？也许有人真有面试需要，但如果是人家用心开发的，为什么不能写在简历中？

【综合】🔥项目有 Java8 版本吗？ ​

有，1.x 版本就是基于 Spring Boot 2.7.x & Java 8 开发的，但早已经停止维护和支持。

分支仓库地址
1.3.xGitee：https://gitee.com/continew/continew-admin/tree/1.3.x/
GitHub：https://github.com/continew-org/continew-admin/tree/1.3.x/

友情提示

  1. ContiNew Admin 1.x 版本，前后端项目均在一个仓库，且没有抽取 ContiNew Starter 组件，前端页面也不是当前演示系统最新效果，风格差异较大，请谨慎选择。

    1.x 版本系统效果图可点击前往回顾 一个界面现代美观，色彩年轻化的Vue3+SpringBoot3前后端分离中后台管理脚手架。

  2. Spring Boot 3.0 于 2022年11月24日 发布，要求从 3.0 开始使用 Java 17 作为最低版本。详情请点击查看 Spring Boot 3.0 发行说明。

  3. Spring Boot 已于 2023年11月24日 结束了 2.7.x 及 3.0.x 版本的社区支持。详情请点击查看 最新支持情况。

  4. Java 8 于 2014年3月18日 发布，这个版本是自 Java 5（发布于2004年）之后的一个重量级版本，也是 Java 发展史上的一个里程碑式的版本，它带来了诸多改进，包括 Lambda 表达式、Streams、日期时间 API 等等。

  5. Java 17 于 2021年9月14日 发布，它是一个长期支持版本（Long-Term-Support - LTS）。从 Java 8 过渡到 Java 17 将带来许多新特性和安全、性能方面的改进。详情请点击查看 Oracle JDK 17 文档。

  6. 根据 JetBrains 2023 开发者生态系统现状调查报告，经常使用的 Java 版本：Java 8（50%）、Java 17（45%）、Java 11（38%）。详情请点击查看 2023 开发者生态系统现状调查报告。

【您访问本文档的时间：2025/1/17 12:45:57】

【综合】项目能开发 Vue2、JS、MyBatis Flex 等等版本吗？ ​

我们欢迎有意愿的大佬扩展 ContiNew 生态并投稿，给更多人群更多选择。

  • Vue2 本项目开始时已经在逐渐被淘汰，所以从未考虑也无计划开发 Vue2 版本。

  • JS 版本我们精力有限，无法维护多个版本。

  • MyBatis Flex，我们有进行调研，如果行业市场普遍采用，我们也会跟进调整技术栈。

  • ...

历史的车轮滚滚向前，ContiNew 项目名称已经体现了（ContiNew，Continue New），我们会持续更新重构，技术栈也将持续跟随行业市场。

【综合】项目什么时候上 Cloud？ ​

除技术栈升级考量外，也考虑到为了 cloud 而 cloud 的市场，我们目前在需求计划中已经列了 continew-cloud 计划，但此需求计划优先级很低，提升优先级的可能性就是近期我所在单位会涉及此类项目开发。如你急需 cloud 版本，请调研其他成熟框架。

我们更关注代码质量和解决方案的细节设计闭环，且业余开源精力有限不急于多线拓展，也无心进行项目推广和竞争。

【综合】项目有商业版吗？ ​

暂无计划。为爱发电，支持赞助。

【综合】项目 dev 分支可以直接用来开发吗？ ​

理论上我们不建议，dev 分支是开发分支，有些重构开发内容并未完成或功能 PR 合并后可能还没有进行代码 review 及功能测试，出现问题概率更高。但如果已经处于版本开发后期，且你精力允许后期跟进升级，可以考虑直接使用。

【综合】🔥项目怎么升级到最新版本？ ​

Admin 项目分为两部分，一部分是写在 Starter 中的通用配置和组件能力，一部分是 Admin 本体中的通用业务代码。

Admin 本体项目是一个代码模板，直白点说就是作者帮你写了一个项目基础的部分代码，你下载后就可以基于现有的代码和规范继续开发你的业务了。

所以理论上 Admin 本体项目谈不上更新，因为你的业务和作者写的通用模板肯定不一样。

但如果你是发现了已有代码的 Bug，或者发现 Admin 更新中修复了某个 Bug，你可以打开对应提交记录，参照着修改对应部分的代码，这也算是一种升级。

如果是 Starter 部分的配置，因为作者已经将 Starter 发布到了 Maven 中央仓库，所以，你可以像升级其他外部依赖（Spring、Hutool 等）版本一样升级它。记得多参考 Admin 本体升级 Starter 版本时的提交记录。

单独开了一篇说明此事，详情请查看《框架更新》。

【综合】多次更换 UI 框架及模板说明 ​

Creator 与 Arco Design 结缘于个人博客项目，认可该 UI 框架的配色方案（好看），同时也认为该 UI 框架的大多数组件足够细腻（好用）。

于是，在 ContiNew Admin 项目初始开发时，确定了 Arco Design Vue 作为 UI 框架，并且选择了官方提供的前端模板（Arco Design Pro）进行扩展开发。直到现在，本人依然认为 Arco Design 这款 UI 框架足够好看好用，甚至它官方推出的前端模板在页面设计上也足够简约大气。

但是，进入实际开发后，本人深刻意识到自己是一位后端开发者，对于前端确实有心无力。尝试封装了一些前端组件，但无论从代码洁癖的角度还是从实用性角度，都不太能达到本人预期。此时也发现 Arco Design Vue 官方推出的 Arco Design Pro 模板更新频率愈来愈低。于是，在经历长时间思量和调研后，（ContiNew Admin >= v3.x ）我们更换前端模板为 林大 开源的（Gi Demo，也称作 Gi Admin Pro ）前端模板。

v3.x 这次更换前端模板的原因，大致如下：

起因：

  1. Arco Design Pro 模板更新频率愈来愈低，很多 Bug 无人修复，依赖也无人升级。（后来已经完全停更，据各方消息，该模板已达到它的使命，所以停止更新）
  2. Arco Design Pro 模板内部组件不成熟（无论是布局还是一些通用工具组件，实际开发发现缺失较多），对于一个专业前端可能还能在其基础上继续增加完善，但对于一个后端开发者，稍显困难，开发体验差。

结论：

  1. Gi Demo 模板基于 Arco Design UI 框架开发，更换前端模板时，3.x 之前的大部分页面代码迁移较为容易。
  2. Gi Demo 模板对于 Arco Design Vue 组件进行了较为丰富的封装，例如：GiForm、GiTable，封装优雅，没有过度封装，实际使用体验佳。
  3. Gi Demo 模板整体样式设计好看。

好好好，那为什么 5.x 还要更换前端模板？

且容喝口水后细说，自 3.x 开发以来，有了 Gi Demo 模板基础组件的加持，前端页面开发表格、表单变得更加容易，开发体验上了一个台阶。但好事多磨，此时 Arco Design Vue 框架的更新频率开始降低，甚至长时间停更....

v5.x 这次更换前端模板的原因，大致如下：

起因：

  1. Arco Design Vue UI 框架更新频率愈来愈低，很多 Bug 已经持续多年未修复。（传闻是某跳动对 Vue 技术栈用得少，所以不够重视）
  2. 从 ContiNew Admin 立项开始，Arco Design UI 框架就属于小众，多年开发后，它依然属于小众。所以，不得不接受一个事实，它确实小众，企业项目选型时，能选择它的也属于小众。
  3. 随着模板开发的深入，也愈发认可一种可持续性较强的前端模板方案，即布局组件自行封装，与 UI 框架解耦（可持续迭代，更灵活，不依赖 UI 框架特性），业务开发则依赖具体 UI 框架，更快捷方便。

未完待续：

  1. 我们也知道目前 ContiNew Admin 项目受众有一部分是 Arco Design 和 Gi Demo 模板圈子的用户，这些用户和我们一样有更高的审美和开发要求，但我们可以确定即使我们更换了 UI 框架，配色方案依然会向 Arco Design 看齐，代码开发依然追求更甜，同时在有了新前端模板的加持，有些更细节的设计将变得更为完善细腻。
  2. 我们将从 Element Plus、Ant Design Vue、Naive UI 等更大众且更新频率较高的 UI 框架项目中选择。
  3. 我们也尽可能调研、选择布局自封装 + UI 框架解耦的前端模板，目前有调研到：Fantastic Admin、Vben 5 等。

针对 5.x 更换前端模板这一计划，目前维护团队还在持续调研中，如果你有好的建议和更好的选择，欢迎能及时提供给维护团队，感谢理解，感谢支持，感谢认可。

【综合】项目启动后，页面空白 ​

Q： 前后端项目均启动成功，访问却是空白页面，打开浏览器控制台也没有报错信息。

A： 交流群内曾有且仅有一位童鞋遇到过此问题，请检查浏览器有没有启用 ublock oragin 扩展组件，如果有请调整规则或在本页面关闭。

【综合】代码生成器生成的代码和预期有差距 ​

Q： 代码生成器生成的代码和预期有差距，有些细节还得自己调整。

A： 此问题仅解答生成效果预期有差距，而不是生成的代码完全不可用。（代码生成内容不可用，请排查是否按照《快速开始》操作正确）

项目内代码生成器是基于 Freemarker 模板 + 配置数据渲染生成的，所以具体生成到什么程度，那完全取决于对应的模板（ftl）和模板里的场景判断细不细。于我个人而言，我的需求就是 利用代码生成器来减少样板化代码的编写 ，像普通的单页面 CRUD 目前它已经能帮我节约 80% 以上的代码时间，我只需要简单调调样式，加一些业务即可完成开发。对于一些稍微复杂的页面，我个人一般是采用复制已有页面的对应代码，根据需要改一改来完成的，相比于没有代码生成器前要编写那么多类和文件，这些复制参考的环节已经属于小 case 了。

所以说，目前设计的代码生成器就是帮你生成大多数的样板化代码，但具体的细节仍需要你参考已有页面自行调整。

随着用户的增长，发现确实有不少用户有更高的代码生成要求：

  1. 主子表场景
  2. 左树右表场景
  3. 弹窗支持选择抽屉或对话框
  4. 支持生成代码到本地
  5. 页面效果可预览
  6. ...

有一些需求用户帮助 PR 完善了模板，有一些需求用户自己本地增加了一些模板和配置。我们维护团队对于代码生成器的这些需求，有一些我们也有考量，后续有些场景我们会丰富，甚至可能会出单独的低代码设计页面，但优先级不高，因为投入和产出比很低。如果，大佬你对这些需求感兴趣，欢迎交流意见，帮助 PR 完善。

【后端】🔥找不到某个 Bean 或访问接口提示 No endpoint ​

A： 毫不夸张，这是像 NPE、404 一样大多数时候都很容易解决的问题。

场景一： 项目启动报错，提示找不到某个 Bean。

Consider defining a bean of type 'xx.xx.xx.Xxx' in your configuration.

场景二： 项目正常启动，访问接口提示 No endpoint XX。

org.springframework.web.servlet.NoHandlerFoundException: No endpoint XXX /xxx/xx.

它们属于一类问题，都是对应的 Bean（包含 Controller） 没有被 Spring 扫描到引起的，你要确认的就是当前你的扫描包配置能不能扫描到对应 Bean/对应 Bean 的实现类/对应 Bean 的配置类等。

要解决这个问题，首先我们需要有几个共识。

  1. Spring Boot Bean 扫描机制
    1. Spring Boot 默认扫描启动类（标注了 @SpringApplication 的类）所在的包及其子包
    2. 通过 @ComponentScan(basePackages = {"xxx", "xxx"}) 可以配置指定一个或多个不同的扫描包
  2. ContiNew Admin 的包扫描配置
    1. 启动类，位于 continew-webapi 模块的 top.continew.admin 包下
    2. 没有单独配置 @ComponentScan，采用的是 Spring Boot 默认的包扫描规则，即默认扫描 top.continew.admin 包及其子包下的 Bean
    3. 在 application.yml 中有一个 project.base-package 配置，当前仅支持单包，是用于本项目内全局枚举字典扫描等场景的

在有了上述共识之后，请你做如下分析排查（if-else-if-else）：

  1. 原版项目（clone 后一个标点符号都没有改动过）是否正常，如原版项目就存在此问题，提个 issue 到开源平台
  2. 是否有改动包结构，如果更改包结构，请把 top.continew.admin 包全部更改完整（如果有涉及模块名更改，请注意不要更改 continew-starter 模块名，它是 Maven 外部依赖，非 Admin 内部模块）
  3. 启动类所在的包能否扫描到报错的 Bean，例如：启动类在 com.example.admin 包下，报错的 Bean 在 com.example.test 包下，这种是无法扫描到的，除非你单独指定了 @ComponentScan(basePackages = {"com.example"}) 或 @ComponentScan(basePackages = {"com.example.admin", "com.example.test"})`
  4. 模块是否有被正确引入或传递引入到 continew-webapi 模块依赖中
  5. 通过 @Bean 注解配置的，请排查对应配置类是否有添加 @Configuration 注解
  6. ...（自行百度/GPT：Spring 扫描不到 xxx）

无关提醒

IntelliJ IDEA 中某些依赖注入下有红线，如果项目能正常启动请忽略，类似问题想解决可以自行百度。

【后端】项目启动后，访问项目 URL 提示跨域错误 ​

在开发环境（dev）的跨域配置中，后端项目配置为了 *，表示放行所有域名。而在生产环境（prod）的跨域配置中，后端项目则配置为了项目前端 URL，所以如果你遇到跨域问题，可以首先确认下后端项目的跨域配置是否正确。

在确认没有问题的情况下，再确认下自己本地是不是开启了 V*N 等代*软件，尝试关闭后再试试。

【后端】项目启动后，CosID 报错误 ​

machineId can't be greater than maxMachine[xx] or less than 0.

将 CosID 的 machine-bit 位数参数调大一些。

【后端】获取图形验证码接口控制台报 load font error ​

在服务器执行如下命令后重启服务。

bash
yum install fontconfig

【后端】项目无法运行， IntelliJ IDEA 报错 Command line is too long ​

Q： 运行项目，IntelliJ IDEA 下加载进度条加载完后没有如期启动程序，而是弹出一个报错小提示框。

Error running ContiNewAdminApplication. Command line is too long.

A： 问题就是字母意思，在这行提示下会有个 Shorten the command line and rerun. 快捷操作超链接，点一下就自动解决并重新运行项目了。

如果还解决不了，百度一下 Command line is too long 即可找到其他解决方案。

【后端】项目整体执行 Maven 编译命令正常，单个子模块则报错 Could not find resource '.style/p3c-codestyle.xml'. ​

Q： 在 continew-admin 这一级执行 Maven 编译（Compile）命令没问题，到了单个子模块执行就报错。报错信息如下：

Could not find resource '.style/p3c-codestyle.xml'.

A： 问题就是字面意思，目前项目采用的代码格式化插件在配置时有点小缺陷。你可以 在 continew-admin/pom.xml 中查看这个代码格式化插件配置，报错的原因就是因为这个配置是在顶级项目中配置的，而且配置的 格式化配置文件 p3c-codestyle.xml 是相对路径，这样到了子模块继承了之后，路径自然是有问题的，所以才会报错。

如果想要解决，目前有下面几个方法：

  1. 将插件的 格式化配置文件 p3c-codestyle.xml 路径配置成 property 变量，在子模块中都各自覆盖下
  2. 将代码格式化插件放到每个子模块中，各自指定好 格式化配置文件 p3c-codestyle.xml 的相对路径
  3. 移除代码格式化插件，改为在 IDE 中引入 格式化配置文件 p3c-codestyle.xml（自行百度）

对于开源项目来说，暂时使用插件感觉更方便，但为了解决这个报错，方案又都不太优雅，所以这事情暂时搁置了，再加上开源项目开发时也都是整体编译，暂时也就忽略了。后面有更好的方案再重构解决。

xml
<build>
    <!-- 代码格式化插件 -->
    <plugin>
        <groupId>com.diffplug.spotless</groupId>
        <artifactId>spotless-maven-plugin</artifactId>
        <executions>
            <execution>
                <phase>compile</phase>
                <goals>
                    <goal>apply</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <java>
                <removeUnusedImports/>
                <eclipse>
                    <file>.style/p3c-codestyle.xml</file>
                </eclipse>
                <licenseHeader>
                    <file>.style/license-header</file>
                </licenseHeader>
            </java>
        </configuration>
    </plugin>
</build>

【后端】开发自己业务，代码格式化后还在自动生成 continew license 头 ​

Q： 开发自己业务代码时，发现只要编译代码就会自动在源代码文件头部生成 license 协议头。

A： 在 continew-admin/pom.xml 中找到代码格式化插件配置，把 <licenseHeader> 配置去除，删除 continew-admin/.style/license-header文件即可。如果你也不需要代码格式化插件，直接移除整个插件，删除整个 continew-admin/.style 目录。

xml
<build>
    <!-- 代码格式化插件 -->
    <plugin>
        <groupId>com.diffplug.spotless</groupId>
        <artifactId>spotless-maven-plugin</artifactId>
        <executions>
            <execution>
                <phase>compile</phase>
                <goals>
                    <goal>apply</goal>
                </goals>
            </execution>
        </executions>
        <configuration>
            <java>
                <removeUnusedImports/>
                <eclipse>
                    <file>.style/p3c-codestyle.xml</file>
                </eclipse>
                <licenseHeader>
                    <file>.style/license-header</file>
                </licenseHeader>
            </java>
        </configuration>
    </plugin>
</build>

【后端】代码生成的功能菜单 SQL 执行插入后，页面还是没有菜单，超管角色功能权限也没有该菜单权限还不能勾选 v3.4.0+ ​

Q： 通过代码生成功能，生成了代码及相关功能菜单 SQL，把菜单数据插入后，刷新页面还是没有菜单数据。而且，超管角色功能权限也没有对应权限，还不能勾选。

A： 在 ContiNew Admin 3.4.0 的代码生成器中增加了自动生成菜单 SQL 功能，所以很多人添加菜单就是从数据库中直接插入了，导致对应菜单缓存没有更新，只需要从 Redis 中把 MENU 相关缓存健全部删除即可。

  1. 超管角色不允许更改功能权限和数据权限，所以页面上不能勾选。
  2. 各个角色的菜单权限有缓存，如果是在页面上操作菜单，缓存能及时清理，如果是在数据库中操作，你懂的。

你是个开发，你又是个 ContiNew 用户，开发的时候你又像个正经用户，我也很难办啊。

【后端】切换到 PostgreSQL 等数据库后，有些功能 SQL 不兼容 ​

Q： 项目目前默认使用的 MySQL 数据库，按照文档切换为 PostgreSQL 后发现了一些兼容问题。例如仪表盘的部分 SQL 查询中很多函数用的是 MySQL 特有的，导致报错。

A： PostgreSQL 是在 ContiNew Admin 项目迭代过程中被多次提起的需求，为此，维护团队在 v2.5.0 版本中增加了对 PostgreSQL 的适配。然而，由于系统迭代、精力受限、缺少 PostgreSQL 环境以及维护团队缺少实际应用等多重因素，我们后续的适配工作只能停留在较为基础的层面（实际上我们已经在尽力的平衡多数据库的兼容性问题，发现一个调整一个，反馈一个调整一个）。

对我个人而言，PostgreSQL 目前并非必需。当然，鉴于当前数据库的发展趋势，适配 PostgreSQL 无疑是必要的，未来我们甚至有可能将项目的默认数据库完全切换至 PostgreSQL。

不过就目前而言，我认为这一过程正是展现开源项目、展现 ContiNew 项目 slogan 魅力的绝佳契机，那些需要使用 PostgreSQL 数据库的童鞋，在实际应用中若遇到问题，积极参与并反馈进来，共同完善好每一个细节。毕竟，只有真实的使用者才能发掘出更多潜在的问题，并助力项目更加完善。在这个过程中，我们也一定会全力提供必要的帮助。

目前已知 SQL 兼容问题：

  1. 仪表盘部分接口 SQL（涉及较多 MySQL 特有函数）

    仪表盘的部分功能，我个人最初想做仅仅是出于好看及提供更多图表示例的目的，这些图表也是我个人思考后选定的，当时还思考过是否会增加项目上手负担，毕竟仪表盘展现什么内容往往具有强业务属性，接口通用性不强。

  2. UserPasswordHistoryMapper 的 deleteExpired 方法

  3. ...

【前端】项目安装依赖提示证书过期 ​

Q： pnpm install 报错，报错提示类似如下：

npm ERR! request to registry.npm.taobao.org failed, reason: certificate has expired

A： 早在 2021 年，淘宝就发文称，npm 淘宝镜像已经从 registry.npm.taobao.org 切换到了 registry.npmmirror.com。旧域名也将于 2022 年 5 月 31 日停止服务（不过，直到近段时间 HTTPS 证书到期才真正不能用了）。

bash
# 清空缓存
npm cache clean --force

# 切换新源
npm config set registry https://registry.npmmirror.com

【前端】点击导出按钮报错 v2.5.0 ​

Q： 点击导出按钮，报错提示如下：

Notification

由于部分模拟数据需要，前端默认启用了 Mock.js，而 Mock.js 会将 responseType 设置为 ''，这不仅会导致关键判断出错，也会导致导出的文件无法打开，实际开发时自行关闭 Mock 即可。

A： 如报错提示所述，实际开发时，打开 continew-admin-ui/src/utils/setup-mock.ts，关闭 Mock 即可。

ts
export default ({ mock, setup }: { mock?: boolean; setup: () => void }) => {
  // 在生产环境也启用 mock
  if (mock !== false) setup(); 
  // if (mock !== false) setup();
};

如有需要，实际开发时，除关闭 Mock 外，同时修改 continew-admin-ui/src/components/crud/index.ts 中的导出错误提示。

【前端】添加完菜单后路由不可用 v2.5.0 ​

Q： 添加完菜单后，点击菜单没有反应，打开控制台后有路由报错。

A： 目前前端项目的动态路由，是采用的基础脚手架 Arco Design Pro Vue 的设计方案 #147，作者称之为半动态路由，所以添加完菜单后，还需要在前端 router 下配置一个对应的静态路由（主要是为了指定其组件地址）。

补充问题

2024/2/22：群友 Joshua 使用时发现如果路由配置到 views/basic 目录，即以 /basic 为路由前缀，会出现配置失效的问题，初步怀疑是由关键词污染导致。

【前端】在目录下只添加了一个菜单，目录不显示 ​

Q： 在目录下只添加了一个菜单，目录不显示。

A： 这是 GiDemo 中的一个小配置，如果目录下只有一个菜单，则不显示目录，而直接显示菜单。可通过还原此提交来恢复仅一个菜单的目录层级展示。目录下仅有一个菜单时平铺展示。

相关处理代码可查阅：continew-admin-ui/src/layout/components/Menu/MenuItem.vue。

【前端】配置好后端接口地址，接口 404 ​

Q： 下载的 2.5.x 版本前端，配置好后端接口地址后，访问页面报接口 404。

A： 前后端版本一定要一 一对应，2.5.x 前端只支持后端 2.5.x 版本，友情建议前后端都升级到最新版本。

【前端】网络控制台里请求的不是后端，是前端地址 ​

Q： 启动后，在浏览器的网络控制台里，请求的 URL 是前端的，而不是后端的。

A： 前端基础知识，请先了解下前端的请求过程，前端请求接口后会代理转发到后端的。详情请点击了解。