Skip to content

常见问题

温馨提示

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

提问的智慧 🔥🔥🔥

温馨提示

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

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

  1. 如果您遇到问题,请先按照 Issue 模板 依次排查确认
  2. 欢迎您在 Issue 中复现存在的问题,Issue 我们必然响应,并且我们非常欢迎您提个 PR 来修复它
  3. 如果您加入了交流群,可以考虑在交流群内与其他用户大佬交流。维护团队成员视个人意愿及空闲时间解答 框架基础使用问题,谢绝技术问题,谢绝微信私信提问
  4. 项目在持续迭代中,此刻调研的您如果觉得它无法满足自身需求,也没有什么亮点,那只说明项目与您的需求不太契合,且仍需要迭代,请口下留情转身调研其他同类框架
  5. 请勿把维护团队当 “许愿池的王八”,如果你的需求场景仅仅是你的业务,请免开尊口
  6. 不接受频繁 “催更”,需求墙里列的后续计划 90% 可能性会做,无非时间精力影响,计划会靠前或靠后而已。所以敬请关注需求墙和群动态

常见差评回复 🔥🔥🔥

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

“道不同,不相为谋”

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

  • 为什么要用你这个,还要增加学习成本?为什么不直接用 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/4/13 22:28:34

项目能开发 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 还要更换前端模板?

且容喝口水后细说,自 v3.x 版本开发以来,有了 Gi Demo 前端模板基础组件的加持,前端页面开发表格、表单变得更加容易,开发体验上了一个台阶。然而,好事多磨,Arco Design Vue UI 框架的更新频率开始下降,甚至出现过长达数周的停更情况。

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

起因:

  1. Arco Design Vue UI 框架的更新频率降低,目前主要由尚不完善的社区进行维护。
  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 框架中选择一款作为 5.x 项目 UI 框架。
  3. 我们也尽可能调研、选择布局(自行封装,不依赖 UI 框架)和 UI 框架解耦的前端模板,目前有调研到:Vben Admin 5、Fantastic Admin、Art Design Pro 等。

针对 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 等代*软件,尝试关闭后再试试。

如何配置多个允许跨域的域名?

Q: prod 配置文件中配置了仅允许 ${project.url} 域名跨域,如何配置多个允许跨域的域名?

A: continew-starter.web.corsallowed-origins 配置是个列表结构,继续追加其他 URL 即可。

yaml
--- ### 跨域配置
continew-starter.web.cors:
  enabled: true
  # 配置允许跨域的域名
  allowed-origins:
    - ${project.url}
    - 其他 URL
  # 配置允许跨域的请求方式
  allowed-methods: '*'
  # 配置允许跨域的请求头
  allowed-headers: '*'
  # 配置允许跨域的响应头
  exposed-headers: '*'

项目启动后,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> // [!code --]
                    <file>.style/license-header</file> // [!code --]
                </licenseHeader> // [!code --]
            </java>
        </configuration>
    </plugin>
</build>

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

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

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

v3.6.0 版本,在菜单管理中增加了缓存清理功能,所以你也可以直接在页面操作一下。

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

🔥切换到 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 特有函数)

    感谢 @李雪松 大佬提供的 LogMapper.xml 涉及兼容方法的修改方案,仅供参考(注意下方不是完整文件,请自行对应替换)。

    xml
    <select id="selectDashboardOverviewPv" resultType="top.continew.admin.system.model.resp.dashboard.DashboardOverviewCommonResp">
        SELECT
            (SELECT COUNT(*) FROM sys_log) AS total,
            (SELECT COUNT(*) FROM sys_log WHERE create_time >= CURRENT_DATE AND create_time &lt; (CURRENT_DATE + INTERVAL '1 day')) AS today,
            (SELECT COUNT(*) FROM sys_log WHERE create_time >= (CURRENT_DATE - INTERVAL '1 day') AND create_time &lt; CURRENT_DATE) AS yesterday
    </select>
    
    <select id="selectDashboardOverviewIp" resultType="top.continew.admin.system.model.resp.dashboard.DashboardOverviewCommonResp">
        SELECT
            (SELECT COUNT(DISTINCT ip) FROM sys_log) AS total,
            (SELECT COUNT(DISTINCT ip) FROM sys_log WHERE create_time >= CURRENT_DATE AND create_time &lt; (CURRENT_DATE + INTERVAL '1 day')) AS today,
            (SELECT COUNT(DISTINCT ip) FROM sys_log WHERE create_time >= (CURRENT_DATE - INTERVAL '1 day') AND create_time &lt; CURRENT_DATE) AS yesterday
    </select>
    
    <select id="selectListDashboardAnalysisPv"
            resultType="top.continew.admin.system.model.resp.dashboard.DashboardChartCommonResp">
        SELECT
            TO_CHAR(create_time, 'YYYY-MM') AS name,
            COUNT(*) AS value
        FROM sys_log
        WHERE TO_CHAR(create_time, 'YYYY-MM') IN
        <foreach collection="months" item="month" separator="," open="(" close=")">
            #{month}
        </foreach>
        GROUP BY name
        ORDER BY name
    </select>
    
    <select id="selectListDashboardAnalysisIp"
            resultType="top.continew.admin.system.model.resp.dashboard.DashboardChartCommonResp">
        SELECT
            TO_CHAR(create_time, 'YYYY-MM') AS name,
            COUNT(DISTINCT ip) AS value
        FROM sys_log
        WHERE TO_CHAR(create_time, 'YYYY-MM') IN
        <foreach collection="months" item="month" separator="," open="(" close=")">
            #{month}
        </foreach>
        GROUP BY name
        ORDER BY name
    </select>
    
    <select id="selectListDashboardAnalysisTimeslot"
            resultType="top.continew.admin.system.model.resp.dashboard.DashboardChartCommonResp">
        SELECT
            LPAD(CONCAT(FLOOR(EXTRACT(HOUR FROM create_time) / 2) * 2, ':00'), 5, '0') AS name,
            COUNT(*) AS value
        FROM sys_log
        GROUP BY name
        ORDER BY name
    </select>
    
    <select id="selectListDashboardAnalysisBrowser"
            resultType="top.continew.admin.system.model.resp.dashboard.DashboardChartCommonResp">
        SELECT
            SUBSTRING(browser FROM 1 FOR POSITION(' ' IN browser) - 1) AS name,
            COUNT(*) AS value
        FROM sys_log
        WHERE browser IS NOT NULL
        GROUP BY name
        ORDER BY value DESC
        LIMIT #{top}
    </select>
  2. UserPasswordHistoryMapper 的 deleteExpired 方法

  3. ...

🔥更新了数据库脚本后,启动项目报错

Q: 跟进了最新的数据库脚本代码(continew-webapi/.../resources/db/changelog下的脚本文件)后,启动项目报错。

A: 请阅读 《Liquibase(数据库版本控制工具)》

使用 SSE 流式传输中断

Q: 使用 SSE 流式传输中断。

A: 原因在于项目引入的 API 请求/响应日志组件 continew-starter-log-interceptor 中定义了一个 LogFilter,目前的解决方法是在配置文件中放行相关 URL。

yaml
--- ### 日志配置
## API 请求/响应日志配置
continew-starter.log:
  # 放行路由
  exclude-patterns: 
    - /xxx

前端

项目安装依赖提示证书过期

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: 前端基础知识,请先了解下前端的请求过程,前端请求接口后会代理转发到后端的。详情请点击了解

🔥使用 pnpm 10.x,启动后报错 The package may have incorrect...

Q: 使用 pnpm 10.x,启动后报如下错误,提示。

Failed to resolve entry for package "@vue-office/docx". The package may have incorrect main/module/exports specified in its package.json.

还会有如下警告:

Ignored build scripts: @vue-office/docx, @vue-office/excel, @vue-office/pdf, core-js, es5-ext, esbuild, vue-demi, vue-echarts.
Run "pnpm approve-builds" to pick which dependencies should be allowed to run scripts.

A: 在 pnpm 10.x 中,有一个重大变化(官方称Major Changes)是:

  • 原文:Lifecycle scripts of dependencies are not executed during installation by default!
  • 译文:默认情况下,安装过程中不会执行依赖项的生命周期脚本!

所以使用 pnpm 10.x 安装依赖时,不会默认执行 vue-office 等依赖的 postinstall 脚本。

解决方法有两个:

  1. 降级 pnpm 版本到 9.x

  2. 仍然使用 pnpm 10.x,但需要执行 pnpm approve-builds 命令(指定哪些包允许执行 postinstall 命令)

=>参考回答