从一开始就是完整工程
移动端、管理端和服务端共享契约，每一层都清楚自己的职责，也知道如何与另外两端协作。
MIT 开源 · Mobile + Admin + Server把 App 的三端，做成一套工程
用 uni-app x 构建 Android、iOS 与 HarmonyOS，用 React 管理业务，用 Go 和 PostgreSQL 承载 API。移动端、管理端和服务端从第一天共享同一套契约。
AppKernia 核心价值
WHY APPKERNIA
做 App，不该从拼接三套脚手架开始
我在一个又一个 App 项目里遇到同样的问题：移动端框架、Admin 模板和服务端脚手架各自都很丰富，可一旦产品要同时支持 Android、iOS、鸿蒙，还要配齐后台、权限、文件、通知和稳定 API，真正困难的部分仍然全部留给开发者。
所以我开始做 AppKernia。它不想成为另一个无所不包的“万能框架”，而是把每个 App 团队都会重复搭建的基础能力连成一条路，让你更快进入真正属于产品的问题。
让重复工作停在底座
把安全、国际化、权限、状态和工程化变成默认能力，把开发时间还给产品体验。
和开发者一起长期维护
选择明确的契约、稳定的依赖和可演进的结构，让项目能被理解、扩展，也能被社区共同改进。
ONE FOUNDATION · THREE SURFACES
一个仓库，把 App 的每一端连起来
这不是三个放在一起的模板。路由、身份、语言、权限和错误码沿着同一份契约流动，每一端只处理自己最擅长的部分。
AK Mobile
面向 Android、iOS、HarmonyOS NEXT 的 uni-app x 基座，使用类型化网络、安全存储、静态路由与 AK UI 组件层。
uni-app x · UTS/UVue · VDOM · AK UI
AK Admin
围绕真实权限、组织、多租户与运营能力构建的管理平台；菜单可见性与后端授权严格分离。
React · Vite · TanStack · Ant Design
AK Server
PostgreSQL-first 的 Go 模块化单体，以 OpenAPI 为事实源，内置认证轮换、审计、任务、文件与通知模块。
GoFrame · pgx/sqlc · PostgreSQL · River
BUILT ON PROVEN TOOLS
一套技术栈，各做自己最擅长的事
uni-app x 连接移动平台，React 组织管理体验，Go 与 PostgreSQL 承载业务和数据，OpenAPI 让三端始终说同一种语言。
uni-app x移动端- React管理端
- TypeScript管理端
- Vite管理端
- Go服务端
- PostgreSQL数据层
- OpenAPI契约
- Docker运行环境
- Ant Design管理端 UI
CORE FEATURES
把通用难题交给底座，把时间留给产品
身份、权限、数据、发布和国际化沿着同一套规则运转，你可以更专注地设计业务，而不是反复修补三端之间的缝隙。
01
会话安全
Access Token、Refresh Token 轮换、Audience 隔离与客户端安全存储形成完整链路。
了解认证模型 →02权限与多租户
前端提供清晰体验，后端与 SQL 负责授权和租户隔离，让权限规则始终有唯一来源。
了解权限模型 →03全链路国际化
zh-CN 与 en-US 覆盖 API、Admin、Mobile 和文档，并共享稳定错误码与回退规则。
理解语言契约 →04OpenAPI 契约
路由、请求、响应与错误从服务端事实源流向生成客户端，减少三端之间的猜测。
浏览 API →05AK UI 适配层
移动业务页面通过统一组件、Props、Event 与 Slot 约定隔离底层平台差异。
查看移动组件 →06可维护的工程基线
迁移、测试、CI 与双语文档随代码一起演进，让新成员更快进入同一套开发规则。
查看开发约定 →CAPABILITY MATRIX
一项能力，三端各司其职
从登录到内容发布，你都可以沿着同一行看清 Mobile、Admin 和 Server 如何分工。
| 能力 | Mobile | Admin | Server |
|---|---|---|---|
| 身份与会话 | 设备标识、安全存储、刷新协调 | 安全 Cookie、会话与 MFA 管理 | Audience 隔离、轮换与撤销 |
| 权限与租户 | 能力门禁与稳定错误码 | 菜单、按钮和数据范围体验 | 后端授权与 SQL 层租户过滤 |
| 内容与运营 | 文章、通知、版本与个人中心 | 内容、文件、任务、配置与审计 | 版本化内容、对象存储和 Worker |
| 国际化 | AkI18n、导航栏与系统格式 | i18next、Ant Design、Day.js | LocaleResolver 与嵌入式 Catalog |
RUN FROM SOURCE
克隆、启动，然后开始改代码
跟着向导完成环境检查、启动完整服务并打开后台。第一次运行之前，你不需要先读懂整个仓库。
获取源码
克隆仓库并进入 AppKernia 根目录。
git clone https://github.com/Payhon/AppKernia.git启动完整后端
Docker 负责 PostgreSQL、迁移、Seed、API 与 Admin。
docker compose up --build -d打开后台
确认服务健康、登录 Admin，再按目标平台进入 Mobile 开发。
curl http://localhost:4173/healthzPRODUCT, END TO END
从运营后台到用户手机，围绕同一份业务继续生长
在 Admin 中管理应用、内容、版本与存储，在 Mobile 中承接登录、通知、阅读与账户体验。两端通过同一套 API 和业务规则自然衔接。
FAQ
开始之前，你可能会问
AppKernia 是一个低代码平台吗？
不是。它提供可审计、可扩展的工程基座和契约，业务仍由开发者用 Go、React、UTS/UVue 实现。
AppKernia 适合什么阶段的项目？
你可以用它评估全栈 App 架构、启动新项目，或参与一套开源基座的建设。项目仍在 0.x 阶段，升级节奏会比较快；准备上线时，请按自己的业务和目标设备补齐安全、性能、备份与平台测试。
为什么特别强调 HarmonyOS？
因为鸿蒙不该是跨端方案最后才补上的平台。AppKernia 从架构开始就把 HarmonyOS NEXT 放进移动端主路径，让组件、路由、网络和工程约定一起演进。
不会 Go 或 UTS 也能贡献吗？
当然可以。你可以复现 Issue、改进文档、审查设计、补充测试、检查平台兼容性或完善翻译；社区页提供了从第一次提交到代码贡献的完整路径。
BUILD WITH US
如果这套方向也解决了你的问题，欢迎一起把它做得更好
从提出一个 Issue、改清楚一段文档，到补上一个组件或平台适配，每次贡献都会让下一位开发者更容易开始。如果你喜欢 AppKernia，也请在 GitHub 留下一颗 Star，让更多正在寻找完整 App 基座的人看见它。