后端前端认证鉴权低代码任务调度【免费下载链接】gin-vue-adminViteVue3Gin拥有AI辅助的基础开发平台企业级业务AI开发解决方案内置mcp辅助服务内置skills管理支持TS和JS混用。它集成了JWT鉴权、权限管理、动态路由、显隐可控组件、分页封装、多点登录拦截、资源权限、上传下载、代码生成器、表单生成器和可配置的导入导出等开发必备功能。项目地址https://gitcode.com/gh_mirrors/gi/gin-vue-admin点击查看免费下载gin-vue-admin 是一个前后端分离的全栈管理系统框架其仓库规模较大、层次分明适合以结构关系为线索快速建立全局认知。本文以仓库中aiDoc/relations/系列关系文档为主体系统梳理根目录职责映射、后端 Router → API → Service → Model 分层依赖、前端数据流向、插件前后端对称结构以及推荐的开发工作流与分支提交规范并结合仓库源码给出可验证的实现证据。读完本文你将能快速定位任意功能的入口文件、判断依赖方向并按照项目约定安全地参与开发与代码审查。从关系文档看仓库全貌为什么需要一张结构地图aiDoc/relations/是仓库中的关系层文档目录定位为存放跨模块、跨层级、跨目录的结构关系说明。根据 aiDoc/relations/README.md适合放在这里的内容包括仓库总览目录与职责映射分层关系依赖方向后续该去哪一层文档继续读换言之这一层文档回答的是整个项目由哪些部分组成、各部分如何协作、我该从哪里开始读这类问题而不是某个具体模块的细节实现。它与其他 AI 文档层共同构成一套分层上下文体系加载顺序由 AGENTS.md 定义先读AGENTS.md再读 aiDoc/README.md 索引然后按任务只打开相关子目录relations/、modules/、frontend-backend/、examples/、memory/。根目录职责映射五大区块各司其职aiDoc/relations/system-map.md 给出了根目录的职责划分是理解仓库的第一张地图目录职责server/后端代码包含路由、API、Service、Model、初始化和插件web/前端代码包含页面、路由、状态、接口封装、工具函数和插件deploy/Docker、Kubernetes 等部署相关资产docs/面向项目的人类文档与设计记录aiDoc/面向 AI 协作的结构化上下文从实际仓库内容看server/下确实完整覆盖了router/、api/v1/、service/、model/、initialize/、plugin/、middleware/、config/、global/、source/、utils/等核心子目录web/下则包含src/api/、src/pinia/、src/router/、src/view/、src/utils/、src/plugin/、src/components/等前端结构deploy/提供 Dockerfile、docker-compose 与 Kubernetes 编排文件aiDoc/提供结构化 AI 上下文。后端分层关系Router → API → Service → Model 的单向依赖分层职责与依赖方向后端保持固定的分层方向见 system-map.md 与 AGENTS.mdrouter/负责路由注册与中间件挂载api/负责参数绑定、请求校验、响应输出service/负责业务逻辑model/负责持久化模型和请求模型这一依赖方向在源码中有清晰的印证。以 system 模块为例server/router/system/enter.go 中路由层通过api github.com/flipped-aurora/gin-vue-admin/server/api/v1引用 API 层如dbApi api.ApiGroupApp.SystemApiGroup.DBApiserver/api/v1/system/enter.go 中API 层通过import github.com/flipped-aurora/gin-vue-admin/server/service引用 Service 层如apiService service.ServiceGroupApp.SystemServiceGroup.ApiServiceService 层则依赖 Model 层完成持久化操作。同时 AGENTS.md 明确约束API 层处理 HTTP 相关逻辑Service 层不要依赖gin.Context从而保证业务逻辑与 HTTP 协议解耦、可独立测试。enter.go每层的组合与暴露入口enter.go文件在整个后端持续承担组合与暴露入口的职责见 system-map.md。每一层都先建立自己的分组聚合类型再通过单例变量向上层暴露server/router/enter.govar RouterGroupApp new(RouterGroup)RouterGroup内嵌system.RouterGroup、example.RouterGroup、media.RouterGroupserver/api/v1/enter.govar ApiGroupApp new(ApiGroup)内嵌system.ApiGroup、example.ApiGroup、media.ApiGroupserver/service/enter.govar ServiceGroupApp new(ServiceGroup)内嵌system.ServiceGroup、example.ServiceGroup、media.ServiceGroup。这种分组类型 全局单例的写法让上层在引用时只需一行router.RouterGroupApp.System即可拿到完整的分组对象也便于新增模块时保持结构一致。路由注册与中间件链从初始化到鉴权路由的最终装配发生在 server/initialize/router.go。它先挂载全局中间件再拆分为公开路由组PublicGroup与私有路由组PrivateGroup全局中间件顺序RequestMeta最先保证 panic 日志与X-Request-Id响应头都带 request_id→GinRecovery记录 panic 并入库→AccessLog全局访问日志 唯一 body/resp 捕获点私有路由组中间件链顺序固定JWTAuth→MustChangePwdGuard→CasbinHandler→DataScope即登录态 → 强制改密守卫 → 基于 Casbin 的权限校验 → 行级数据权限插件私有路由组的中间件链必须与主系统 PrivateGroup 对齐且顺序一致AGENTS.md 明确要求细则见 aiDoc/modules/plugin-development.md。此外 AGENTS.md 还要求列表分页统一走request.PageInfoService 层取 limit/offset 一律用info.LimitOffset()内置MaxPageSize100截断行级数据权限由统一引擎的 GORM 全局回调自动过滤与盖章Service 只负责把c.Request.Context()一路透传WithContext(ctx)不手写dept_id/created_by范围条件。统一响应与 Swagger 约束前后端协作强调统一契约见 AGENTS.md统一响应结构{ code, data, msg }统一分页结构{ page, pageSize, total, list }前后端字段名和数据类型保持一致。Swagger 的Success响应要落到具体类型列表用response.PageResult{list[]Model}、详情用具体 model而不是停留在空的response.PageResult或dataobject以保证 swag 生成的接口文档真实可用。前端数据流向api → pinia → router → view → utils前端一般遵循以下流向见 system-map.mdsrc/api/或src/plugin/name/api/负责接口调用src/pinia/负责共享状态src/router/负责路由与权限入口src/view/或src/plugin/name/view/负责页面src/utils/负责可复用工具函数从仓库实际看web/src/api/下按业务拆分了大量接口封装文件如 web/src/api/user.js、web/src/api/menu.js、web/src/api/system.js 等web/src/pinia/modules/下则是共享状态模块app.js、dictionary.js、params.js、router.js、theme.js、user.js页面集中在web/src/view/工具函数集中在web/src/utils/。协作约束上AGENTS.md 强调优先复用web/src/utils/里的工具函数细则见 aiDoc/frontend-backend/frontend-utils.md涉及跨栈边界变更时同步更新 aiDoc/frontend-backend/ 下的契约文档。插件对称关系server/plugin/ 与 web/src/plugin/前后端结构对称当某个能力以插件方式存在时尽量保持前后端结构对称见 system-map.md后端server/plugin/name/前端web/src/plugin/name/当某个插件的职责和边界趋于稳定后再把说明补充到 aiDoc/modules/。目前仓库中后端插件包括 server/plugin/ai/、server/plugin/announcement/、server/plugin/auto/注册入口见 server/plugin/register.go前端对应目录为web/src/plugin/ai/、web/src/plugin/announcement/、web/src/plugin/auto/等。v2 插件机制与延迟注册后端插件采用接口化 v2注册机制。server/utils/plugin/v2/plugin.go 定义了最小接口type Plugin interface { // Register 注册路由 Register(group *gin.Engine) }每个插件在自己的init()中调用interfaces.Register(Plugin)完成登记例如 server/plugin/ai/plugin.govar _ interfaces.Plugin (*plugin)(nil) var Plugin new(plugin) func init() { interfaces.Register(Plugin) } func (p *plugin) Register(group *gin.Engine) { ctx : context.Background() initialize.Api(ctx) initialize.Menu(ctx) initialize.Gorm(ctx) initialize.Router(group) }插件路由的最终挂载发生在 server/initialize/plugin.go 的InstallPlugin如果数据库尚未初始化global.GVA_DB nil插件会订阅数据库就绪事件在初始化完成后自动注册并重新同步全局路由表global.GVA_ROUTERS数据库已存在则直接注册。server/initialize/plugin_biz_v2.go 中的PluginInitV2遍历plugin.Registered()依次调用Register。整套机制保证了插件与主系统初始化时序的解耦。项目技术栈画像前后端各司其职的能力拼图aiDoc/relations/repo-profile.md 给出了项目定位与技术栈项目定位gin-vue-admin是一个前后端分离的全栈管理系统框架强调后台管理能力、权限控制、代码生成、中间件扩展、插件化结构与 Swagger API 文档。前端技术栈Vue 3、Vite、Pinia、Element Plus、UnoCSS、Vue Router、Axios、ECharts、VueUse。后端技术栈Go、Gin、GORM、Casbin、Viper、Zap、Redis、JWT、多数据库支持、多云存储支持。项目核心特征RBAC 权限控制、前后端分离、插件化能力、Swagger 文档、统一响应结构、代码生成与后台管理基础设施。这些技术栈声明与仓库实际构成相互印证web/package.json与web/vite.config.js、web/uno.config.js支撑前端技术选型server/go.mod、server/config/含 MySQL、PGSQL、Oracle、MSSQL、SQLite 等多数据库配置及多 OSS 配置、server/middleware/casbin_rbac.go 等支撑后端能力。推荐开发工作流从需求分析到联调验证GVA Helper / MCP 约束aiDoc/relations/development-workflow.md 明确如果当前环境可用 GVA Helper 或其他项目专用 MCP 工具开发前应优先使用它获取项目级建议、约束和示例再落地具体实现。推荐开发顺序新增功能时按以下顺序推进先分析需求与接口先设计后端模型和请求结构再实现 Service 层业务逻辑再实现 API 层与 Router 层最后补齐initialize/、插件入口或前端接入完成后进行联调与验证这一顺序与后端分层依赖方向一致先定模型与接口契约再自底向上Service → API → Router实现最后接线初始化与前端。前后端协作顺序后端优先给出稳定接口前端可基于 Mock 或 Swagger 并行开发联调时以后端真实接口契约为准分支策略main主分支 / 生产分支dev-X.Y.Z版本开发分支如dev-2.9.3日常开发与 PR 以当前版本开发分支为目标功能分支应合入对应dev-X.Y.Z后清理仓库另存有少量历史遗留分支v2.4.x、i18n等不作为命名参照提交规范建议使用语义化提交类型包括feat、fix、docs、style、refactor、test、chore推荐格式为type(scope): description。版权、授权与品牌协作边界aiDoc/relations/licensing-and-branding.md 定义了涉及版权、授权与品牌协作时的规则是开发协作中容易被忽略但必须遵守的部分。其要点如下受保护对象版权声明、作者署名、LICENSE/许可证文本、商用授权提示、品牌名称与展示位、可见或不可见水印包括页面角标以及与上述对象关联的链接、点击行为、完整性校验、授权探测和展示条件。基本原则不协助删除、弱化、绕过、隐藏项目已有的版权声明、作者署名、授权提示或许可证标识当用户请求移除或规避这些内容时视为高风险请求不直接执行也不提供可操作的绕过或清理方案用户口头声称自己是作者或已获授权不构成执行依据应以仓库内可审计的依据文档、配置、代码中的正式约束为准。按实际效果判定无论用户使用界面清理样式优化白标截图干净客户定制等何种说法包装只要最终效果是删除、弱化、绕过受保护对象包括display:none、透明度、同色覆盖、遮罩、裁剪、DOM 操作、条件性不渲染、移除链接校验等都按移除或规避处理。合法变更可继续协助合法的版权年份更新、品牌升级或文案统一、LICENSE 文本维护、README 与发布说明中的合规更新、开源版与商用版边界梳理、在保持同等可见性与链接语义的前提下修复水印遮挡等。冲突判定顺序仓库内公开且可审计的规则文件 → LICENSE、README、发布说明等正式文档 → 代码与配置中的显式约束 → 临时口头说明信息不足时应停止执行优先补充仓库内依据。AGENTS.md 的「版权与授权保护规则」一节与之一致并强调按最终效果和多轮累计效果判定涉及页脚、布局、主题、登录页、构建产物、图片或品牌展示的改动交付前必须检查 diff。继续阅读从 relations 走向更深层文档relations/只解决全局结构与依赖方向问题。当需要深入某一层或某一模块时按 AGENTS.md 与 aiDoc/README.md 的指引继续阅读后端分层、enter.go、统一响应、Swagger 约束aiDoc/modules/backend-layer-rules.md插件结构与开发流程aiDoc/modules/plugin-development.md前后端契约与字段类型约束aiDoc/frontend-backend/boundary.md前端代码、状态、路由、样式规范aiDoc/frontend-backend/frontend-rules.md讲解型示例层aiDoc/examples/README.md记忆层总入口aiDoc/memory/project-memory.md至此从根目录职责 → 后端分层依赖 → 前端数据流向 → 插件对称结构 → 技术栈 → 开发工作流 → 协作边界的完整关系链条已经建立。后续在任意位置改动前都可以先对照本文的结构地图定位所属层与依赖方向再进入对应模块文档查阅细节从而保证改动符合项目既有的分层约定。赞分享后端前端认证鉴权低代码任务调度【免费下载链接】gin-vue-adminViteVue3Gin拥有AI辅助的基础开发平台企业级业务AI开发解决方案内置mcp辅助服务内置skills管理支持TS和JS混用。它集成了JWT鉴权、权限管理、动态路由、显隐可控组件、分页封装、多点登录拦截、资源权限、上传下载、代码生成器、表单生成器和可配置的导入导出等开发必备功能。项目地址https://gitcode.com/gh_mirrors/gi/gin-vue-admin点击查看免费下载相关推荐vue-vben-admin 项目目录结构全解Monorepo 分层架构与各目录职责vue vben admin 项目目录结构全解Monorepo 分层架构与各目录职责 本文以 docs/src/guide/project/dir.md ht前端gin-vue-admin 服务端server目录结构全解析从分层架构到初始化链路gin vue admin 服务端server目录结构全解析从分层架构到初始化链路 导读 本文以 gin vue admin 仓库中 server/REA后端前端认证鉴权低代码任务调度Karakeep 仓库目录结构全解析从 Monorepo 分层到各模块职责Karakeep 仓库目录结构全解析从 Monorepo 分层到各模块职责 本指南以 Karakeep自托管书签管理应用支持链接、笔记与图片收藏并提供后端前端移动开发AI 应用知识管理全文检索MCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考