Reglow 基础库改造与集成 —— 小白实操手册
将 ReglowAdmin 通用后台拆解为基础库(pip/npm 包),供像匠项目直接复用,零重复开发。V0.3.1 版本。
版本:V0.3.1
更新日期:2026-06-29
适用场景:将 ReglowAdmin 通用后台拆解为基础库(pip/npm 包),供像匠(xiangjiang_project)直接复用,零重复开发。V0.3.1 修正:对齐 Reglow 实际代码(
coding/backend-python/main.py与各模块router.py),更正虚构的「三端 Router」约定为实际的「单router+ 可选client_router」模式;用户端路由前缀更正为/api/v1(非/app/api/v1);store 模块示例改为 Controller 显式构造 Service 的依赖注入风格;补dependencies_client.py、svg.path>=7.0、菜单 icon 用@radix-icons/vue组件引用等遗漏点。
写在前面:一个大白话故事
核心思想就一句话:
Reglow 基础库 = 麦当劳总部配方和运营系统。像匠后台 = 一家照相馆主题的麦当劳。系统直接复用,只建照相馆业务页面。
像匠不需要从零搭建后台界面。ReglowAdmin 的布局框架、组件库、登录页、用户管理页等全部可以直接复用。
目录
- 理解 ReglowAdmin:它到底提供了什么
- 改造总览:一张图看懂拆与合
- Backend:后端改造手把手
- Frontend:前端改造手把手
- 像匠开发实战:怎么最快上手
- 像匠后台需要写什么、不用写什么
- 对 Reglow 自身的影响
- 版本升级:怎么升得科学又不踩坑
- 日常开发工作流
- 十条铁律:记住了就不会走偏
一、理解 ReglowAdmin:它到底提供了什么
1.1 产品定位
ReglowAdmin 是一个架构先行的通用后台基座,不是简单的 CRUD 生成器。它遵循 5 条设计心法(来自 likeadmin 经验总结):
| 心法 | 要义 | 大白话 |
|---|---|---|
| 心法① 目录按模块分 | 高内聚低耦合 | 一个功能的所有代码放一个文件夹,别撒得到处都是 |
| 心法② 每层只做自己的事 | 单一职责 | Controller 不写业务,Service 不写 SQL,Model 纯定义 |
| 心法③ 依赖注入替代 new | 控制反转 | 不用自己 new 对象,框架自动给你组装好,测试时轻松换假数据 |
| 心法④ 声明式验证 | 类型即文档 | Schema 定义好字段类型和规则,数据自动校验,Swagger 自动生成 |
| 心法⑤ 横切关注点下沉 | 业务代码零污染 | 租户/日志/权限交给中间件,业务代码只管写业务 |
1.2 架构分层:五层分工
类比奶茶店:
- Controller = 收银员(接单、传单、出餐)
- Schema = 菜单模板(顾客只能点菜单上有的)
- Service = 掌勺大厨(决定奶茶怎么做,配方在这)
- Repository = 仓库管理员(管茶叶、奶精、珍珠,只负责取放)
- Model = 食材规格书(珍珠直径 8mm,奶精保质期 7 天)
1.3 多端入口分离:管理端与用户端物理隔离
ReglowAdmin 采用 Router 分包 策略,两端独立路由树、独立鉴权链(基于实际 main.py 实现):
关于「开放接口端(Open API)」:当前 ReglowAdmin 尚未实现
/open/api/v1第三方对接端。若像匠需要对接外部系统,作为 P3 阶段扩展,在main.py中追加open_api = APIRouter(prefix="/open/api/v1")即可,参考下方对比表预留设计。
两端隔离对比(含 Open API 预留设计):
| 维度 | Admin API | Client API(实际) | Open API(预留) |
|---|---|---|---|
| 路由前缀 | /admin/api/v1 | /api/v1 | /open/api/v1 |
| 认证方式 | JWT(账号密码) | JWT(手机号/微信) | API Key / OAuth2 |
| 权限 | RBAC(菜单+按钮+数据) | 本人数据 | ACL 按 Key 授权 |
| 限流 | 600次/分钟 | 120次/分钟 | 60次/分钟 |
| 敏感字段 | 全返回 | 脱敏 | 掩码 138****1234 |
| 内容过滤 | 全状态 | 仅已发布 | 仅已发布 |
| Token 有效期 | 2h + 7d | 7d + 30d | 永久(可吊销) |
| 依赖文件 | core/dependencies.py | core/dependencies_client.py | 待新建 |
1.4 权限体系:三维一体
1.5 ReglowAdmin 现有功能模块一览
二、改造总览:一张图看懂拆与合
关键关系
三、Backend:后端改造手把手
3.1 第一步:创建 pyproject.toml
在 reglow_project/ 根目录创建:
3.2 第二步:移动目录结构
3.3 第三步:批量修正内部 import
改造后,reglow 包内部代码的 import 全部从 from core.xxx 改成 from reglow.core.xxx:
| 旧写法 | 新写法 |
|---|---|
from core.config import get_settings | from reglow.core.config import get_settings |
from core.database import get_db, Base | from reglow.core.database import get_db, Base |
from core.security import verify_token | from reglow.core.security import verify_token |
from core.dependencies import get_current_employee | from reglow.core.dependencies import get_current_employee |
from core.dependencies_client import get_current_client_user | from reglow.core.dependencies_client import get_current_client_user |
from common.response import ApiResponse | from reglow.common.response import ApiResponse |
from common.exceptions import AppException | from reglow.common.exceptions import AppException |
from modules.xxx.model import ... | from reglow.modules.xxx.model import ... |
操作技巧:在 VS Code 中,用「全局搜索替换」(Ctrl+Shift+H),正则模式:
from core\.→from reglow.core.from common\.→from reglow.common.from modules\.→from reglow.modules.只替换
reglow/目录下的文件。注意:
core/dependencies_client.py是用户端鉴权入口(导出get_current_client_user),不要漏移;否则modules/*/controller_client.py会全部 import 报错。
3.4 第四步:模块 Router 的真实约定
改造后每个模块的 router.py 只导出一个主 router(管理端用),如需用户端再追加 client_router。命名遵循实际代码约定,不要臆造 admin_router / app_router / open_router 三件套。
Controller 内部怎么写(以 Article 为例,对齐真实代码)
用户端怎么挂(参考 modules/user/controller_client.py 模式)
重要约定:
- 管理端主 Router 变量名固定为
router(不要叫admin_router)。- 用户端 Router 变量名固定为
client_router(不要叫app_router)。prefix在模块内部APIRouter(...)上声明,不靠main.py的include_router(prefix=...)补,避免路径散落两处。- 额外子 Router(如
material.group_router、message.inbox_router)按需追加,命名见仁见智但要在router.py中显式__all__暴露。
3.5 本地开发安装方式
四、Frontend:前端改造手把手
4.1 建立 @reglow/ui npm 包
在 reglow_project/coding/frontend-admin/ 下改造:
4.2 统一导出入口
4.3 像匠前端如何安装
五、像匠开发实战:怎么最快上手
5.1 Backend:像匠的 main.py
对齐 Reglow 实际
main.py风格:所有 Router 用APIRouter(prefix=...)在各自模块内声明 prefix,main.py只负责挂载和组装,不重复声明 prefix。
关键差异 vs 改造前的旧写法:
旧写法(错误的) 新写法(对齐实际 reglow) from reglow.modules.auth.router import admin_routerfrom reglow.modules.auth.router import routeradmin_app.include_router(auth_router, prefix="/auth")admin_api.include_router(auth_router, tags=["认证"])app.mount("/admin/api/v1", admin_app)用 sub-app 挂载app.include_router(admin_api)用 APIRouter 合并用
include_router+ 顶层prefix而非app.mount,所有路由在同一个 FastAPI 实例下,OpenAPI 文档统一生成,CORS / 中间件只配置一次。
5.2 Backend:像匠的业务模块怎么写
以「门店管理」为例,完全遵循 Reglow 的五层架构。所有文件都在 app/store/ 一个目录内。
依赖注入模式(对齐 Reglow 实际代码):
- Controller 层用
Depends(get_db)注入AsyncSession,再显式构造 Service:service = StoreService(db)。- Service 层不依赖 FastAPI 的
Depends(),构造函数直接接收db: AsyncSession(也可以接收 Repository)。- Repository 层同样接收
db: AsyncSession,由 Service 构造或 Service 内部使用。这样 Service / Repository 是纯 Python 类,可以脱离 FastAPI 在单元测试里直接
StoreService(fake_db)构造,符合心法③「依赖注入」。
三个关键模式(与 reglow 实际代码一致):
- Controller 显式构造 Service:
service = StoreService(db),而不是service: StoreService = Depends()。后者也能跑,但 Service 类就被 FastAPI 接管,单测时需要 mock 容器,更复杂。Reglow 现网代码采用前一种简洁写法。- Service 不导
Depends:构造函数__init__(self, db: AsyncSession)是纯 Python,不挂 FastAPI 装饰。单测可以直接StoreService(fake_db)。prefix在模块内APIRouter(...)上声明,main.py的include_router不传 prefix,路径只在一处维护。
5.3 像匠项目目录结构总览
重要:业务代码同样遵循心法①「按模块分」。不能因为写的是业务代码就退回按层分。
为什么业务代码也要按模块分?
心法①「目录按模块分」是一条通用原则,不看代码是「框架」还是「业务」。只因为它是业务代码就退回按层分,等于前半程走高铁、后半程走土路——快不起来。
深层原因:
| 维度 | 按层分 | 按模块分 |
|---|---|---|
| 心智负担 | 5 个目录,脑中拼图 | 1 个目录,所见即所得 |
| 改漏风险 | 改 service 忘了改 schema → Bug | 同目录 5 文件一字排开,不会漏 |
| 删模块 | 5 个目录各删 1 个,漏删报错 | 删 app/order/ 整个文件夹 |
| 新人上手 | 「订单代码在哪?」说不清 | app/order/ |
| 拆微服务 | 5 个目录捞文件,拆不动 | 拎出 order/ 一个目录 |
一句话:代码是给业务服务的,当然按业务组织。不管是框架还是业务,组织原则一视同仁。
六、像匠后台需要写什么、不用写什么
一张表看清
| 你需要写的 ✅ | 你不需要写的 ❌(@reglow/ui 直接给) |
|---|---|
| 门店管理页(列表/新增/编辑/上下架) | 登录页(账号密码 + 验证码 + 短信登录) |
| 订单管理页(列表/详情/状态流转) | 注册页(选部门 + 填信息) |
| 修图工作台(任务分配/处理/交付) | 管理员管理页(CRUD + 部门 + 岗位) |
| 产品/团购管理页 | 角色权限管理页 |
| 预约管理页(日历视图+列表) | 菜单管理页(树形结构) |
| 财务报表页(营收/对账) | 部门管理页(组织架构) |
| 营销活动页 | 字典管理页 |
| 摄影师管理页(扩展信息) | 系统设置页(短信/存储/备案) |
| 操作日志页 | |
| 素材中心(图片/视频上传) | |
| 通知公告页 | |
| 布局框架 | AdminLayout(侧边栏+顶栏+标签页+面包屑) |
| 照相馆菜单配置 | reui 组件库(表格/表单/弹窗/上传/编辑器/日期选择器...) |
| API 客户端(认证拦截+错误处理+请求封装) |
像匠 App.vue 示例
图标约定:
@reglow/ui的peerDependencies是@radix-icons/vue,所以菜单 icon 传组件引用而非字符串名(如icon: StoreIcon,而不是icon: "mdi-store")。否则在像匠项目里要额外安装 mdi 图标库,与基础库脱节。
七、对 Reglow 自身的影响
7.1 Reglow 自己也变成消费者
改造后,ReglowAdmin 自己的 main.py 变得和像匠一样:
好处:Reglow 自己成为基础库的第一个用户。如果自己都用不顺,别人肯定也用不顺——倒逼基础库质量。
7.2 影响一览
| 维度 | 改造前 | 改造后 | 影响程度 |
|---|---|---|---|
| 目录位置 | coding/backend-python/ | reglow/(核心) + reglow-app/(应用) | 🟡 中等 |
| import 路径 | from core.xxx | from reglow.core.xxx | 🟡 中等 |
| 启动方式 | python main.py | pip install -e . 后同样 python main.py | 🟢 不变 |
| 开发体验 | 改代码即生效 | -e 可编辑安装,同样即时生效 | 🟢 不变 |
| 复用方式 | 只能复制代码 | pip install reglow | 🟢 质的飞跃 |
| 版本管理 | 没有版本 | 语义化版本 0.2.1 → 0.3.0 → 1.0.0 | 🟢 新增能力 |
| 代码质量 | 耦合 | 边界清晰,基础库修改更谨慎 | 🟢 提升 |
| Git 历史 | 保留 | 用 git mv,历史完整保留 | 🟢 保留 |
八、版本升级:怎么升得科学又不踩坑
8.1 版本锁定策略
8.2 升级标准流程
8.3 Reglow CHANGELOG 示例
九、日常开发工作流
9.1 「像匠需要某功能」时怎么做
9.2 本地联调配置
9.3 FAQ
Q:像匠的数据库表会跟 Reglow 冲突吗?
A:不会。Reglow 的表统一 sys_ 前缀(sys_employee、sys_user...),像匠的业务表用 xj_ 前缀(xj_store、xj_order...),泾渭分明。
Q:想改某 Reglow 模块的逻辑怎么办?
A:三种方法,按推荐序:
- 继承覆写:
class XiangJiangAuthService(reglow.modules.auth.AuthService),重写方法 - 向 reglow 提 PR:确实通用的改动,合入基础库,所有项目受益
- 完全自己写:改动太大,在像匠里独立实现,不用 reglow 的这个模块
Q:Reglow 删除了我依赖的函数?
A:这属于 Breaking Change,必须升 MAJOR 版本号。升级前看 CHANGELOG,适配完再升。
Q:升级后某些接口不通了?
A:先降回旧版本(pip install reglow==旧版本),然后对照 CHANGELOG 排查。不要硬升。
附:十条铁律记住了就不会走偏
| # | 铁律 | 一句话 | 违反后果 |
|---|---|---|---|
| 1 | 公共抽出来,独有留下来 | 换个项目还要吗?要→放 reglow,不要→留像匠 | 通用代码散落各处,Bug 修 N 遍 |
| 2 | 依赖不改源码 | 只在 reglow 仓库改基础代码,不在下游改 | 一升级就覆盖,改动全丢 |
| 3 | 版本锁死 | 生产 ==0.2.1,开发 ~=0.2.1 | 自动升到不兼容版本直接炸 |
| 4 | 每次发版写 CHANGELOG | 写清楚:新功能 / 修复 / ⚠️ Breaking Change | 下游不知道变了啥,不敢升级 |
| 5 | 升级先看日志再跑测试 | 任何红灯不能上线 | 带着 Bug 上线 |
| 6 | 五层架构不跨层 | Controller→Schema→Service→Repository→Model | 绕开 Service 直接调 Repository,业务规则落空 |
| 7 | 两端 Router 分清楚 | 管理端导 router,用户端追加 client_router(不叫 admin_router/app_router) | 权限串漏,用户端拿到管理后台数据 |
| 8 | 声明式验证不进 Service | Schema 层拦截脏数据 | 手写 if 校验散落 Service,漏一个就出事 |
| 9 | 表前缀隔离 | Reglow 用 sys_,像匠用 xj_ | 表名冲突,数据错乱 |
| 10 | 像匠自己也是组装者 | main.py 只做组装,不写业务 | 启动入口越来越臃肿 |
最后记住:Reglow 基础库 = 麦当劳总部配方和运营系统。像匠 = 用这套系统开的照相馆。总部配方升级,全部分店自动受益。像匠只操心照相馆自己的菜品——门店、订单、修图。
不是"从零搭建",是"拿过来就用的壳 + 自己填的业务内容"。
