9.6 KiB
9.6 KiB
参考:移植经验与踩坑记录
全程参考此文档,避免重蹈覆辙。每完成一个模块,将新经验追加到本文档。
前端经验
1. 附件上传必须遵循门户标准
- 替换为
fetchUploadAttachment - 上传触发样式遵循「附件上传卡片化布局」(140×96px)
- 参考
openspec/.../ui-conventions/spec.md§「附件上传卡片化布局」
2. 弹窗统一用 el-dialog,禁止 el-drawer
el-drawer→el-dialogsize="80%"→width="960px"- 移除
direction="rtl" - 添加
backdrop-filter: none、class="dialog-form-layout"
3. 详情查看弹窗按 OpenSpec 标准样式
- 使用
SystemViewDialog模式(参考ProductViewDialog.vue) - 状态字段用
<el-tag>渲染
4. 表单字段注释放在 label 后面
<template #label>排序号<span class="form-label-tip">数值越小越靠前</span></template>
5. Element Plus 组件不要手动 import
- shanxia2.0 使用自动导入,删除所有手动 import
6. 视图切换保留原 CRM 组件
el-radio-group+el-radio-button是 Element Plus 原生组件,保留不变
13. API 响应解包用兼容写法
request.post内部已解包res.data.data,返回值是 API 的data字段内容- 但加密/非加密场景返回结构不一致,必须用兼容写法:
const data = (res as any)?.data || res || {} list.value = data.list || data.rows || [] - 禁止直接写
res.data?.list(多套了一层.data,结果为undefined) - 参考已有页面的写法:
product/index.vue、customer/index.vue
14. 字典类型名必须匹配 API 实际返回值
- 同一业务概念可能存在多个字典(如行业:
crm_industry中文值 vscrm_customer_industrycode 值) - 必须先看 API 实际返回的 dict_value 是什么格式(中文?code?),再选择对应的
dict_type - API 返回
industry: "it_internet"→ 用crm_customer_industry - API 返回
industry: "石油化工"→ 用crm_industry - 在模板和
dictStore.getLabel()/dictStore.getTagType()中使用匹配的字典名
15. 跨模块组件直接引用,不要重新实现
- 已有模块的通用组件(如
CustomerDetailDialog、ClaimDialog)应直接 import 使用 - 公海池查看详情 → 引用
../CustomerDetailDialog.vue,不要写占位ElMessage.info('功能开发中') - 新模块的"查看"按钮:先搜索是否已有同类型的详情弹窗组件
16. 下拉选择器加载全量用户时注意 pageSize 上限
- 后端用户列表等通用 API 有
pageSize上限(le=100) - 下拉选择器不能传
pageSize: 1000,会触发 422 错误 - 传
pageSize: 100,如果用户超过 100 人需要支持搜索过滤(filterable)
后端经验
7. 编号自动生成
- CRUD 层实现,查询当日最大编号 +1,跨日重置,租户隔离
8. 唯一性校验排除软删除
- 校验查询加
del_flag=0
9. 关联统计字段同步更新
- 新增/删除关联记录时同步更新主表统计字段
10. 先理解 Java 再写 Python
- 先找 Java Controller → Service → Mapper 完整调用链
- 用中文写业务逻辑说明
- 注意:事务范围、级联更新、校验顺序、异常处理
- 特别注意 Java 代码中的注释,原 CRM 的注释往往包含关键业务规则(如"不清空 ownerUserName,保留原负责人姓名")
17. 状态变更时必须保留关联展示字段
- 客户放入公海池(
status → pool)时,owner_user_id清空但owner_user_name不能清空 - 原 CRM 明确注释:"保留原负责人姓名用于公海池列表显示"
- 原则:ID 字段可以清空(关联已断开),但冗余的姓名/展示字段必须保留(用于历史记录展示)
- 移植前必须逐行对比原 CRM 的
set语句,确认哪些字段清空、哪些保留
18. 历史数据修复必须配套 SQL
- 代码逻辑修复后,已被错误逻辑破坏的历史数据需要 SQL 回填
- 回填 SQL 写在增量脚本末尾,用
INNER JOIN sys_user等关联查出名字回填 - 示例:
UPDATE crm_customer c INNER JOIN sys_user u ON c.into_pool_by = u.id SET c.owner_user_name = u.nick_name WHERE c.status = 'pool' AND c.owner_user_name IS NULL
数据库经验
11. DDL 与 ORM 字段顺序一致
- DDL 和 Model 保持相同排列顺序
12. SQL 增量脚本必须保存
- 每次建表/ALTER TABLE 时输出增量 SQL 到
docs/sql/
线索管理模块经验(2026-05-31 新增)
19. 转化逻辑必须在事务中执行
- 线索→客户转化涉及两张表(crm_clue + crm_customer),必须用事务
db.add(customer)→db.flush()→ 更新线索 →db.commit()- CrmCustomer.clue_id 回写线索 ID,建立反向关联
- 转化前必须校验:已转化/无效线索不可重复转化
20. 跟进记录级联更新线索 4 个字段
- 新增跟进后必须更新线索:
last_time=now, follow_count+1, next_time=跟进.nextTime, status='follow' - 删除跟进不回退 followCount(原 CRM 设计决策)
- 修改跟进时如果 nextTime 变更,需同步更新线索 nextTime
21. 前端适配先拷贝再逐行修改,不要直接新写
- 先将原 CRM 的 Vue 文件原样拷贝到 shanxia2.0
- 然后按差异对照表逐行阅读理解后修改
- 好处:保留原 CRM 完整的表单字段/验证规则/交互逻辑,不会遗漏
22. el-drawer→el-dialog 布局需调整
- 抽屉是侧边全高,弹窗是居中固定宽度
- 抽屉内左右分栏布局(左信息+右 Tab)需调整为弹窗内垂直布局
- detailDrawer.vue 从 ~900 行抽屉改弹窗后仍保持完整功能
23. 多视图 Tab 列表页共用同一个查询函数
- 5 个视图(我的/全部/待跟进/今日新增/已转化)条件不同但基础表相同
- 后端用一个 list_clues 函数 + view_mode 参数切换 WHERE 条件
- 前端根据当前 Tab 调用不同的 API 函数(fetchMyClueList / fetchToFollowClueList 等)
24. 附件上传用 AttachmentUploadField 组件
- 跟进记录弹窗原 CRM 有 ~300 行自定义上传样式代码
- 替换为 shanxia2.0 已有的
AttachmentUploadField组件后缩减到 ~190 行 - 参考
customer/FollowFormDialog.vue的附件实现
25. 操作日志 Tab 暂不迁移
- 原 CRM 详情页有"操作日志" Tab,调用
/monitor/operlog接口 - shanxia2.0 可能没有此接口,注释掉 Tab 并加 TODO
- 后续根据 shanxia2.0 审计日志能力决定是否实现
26. 线索模块 — 快速搜索勿用多字段 AND
- 列表快捷搜索应传单一
keyword,后端 OR 匹配clueName/mobile/company - 勿把同一关键词同时写入
clueName、company、mobile(会变成 AND,几乎查不到)
27. 线索模块 — 批量操作要处理 failItems
- 删除/分配/无效等批量接口可能部分失败(如已转化线索)
- 前端须解析
successCount/failItems,勿一律ElMessage.success
28. 线索按钮权限用 menuCodes 而非 v-auth
- 门户
v-auth依赖路由authList,静态路由未配置时无效 - 线索页使用
useCluePerm+/web/auth/menu-codes映射crm:clue:*
29. Excel 导出必须集中做字典 code→label(对齐 Java ExcelDictConvert)
- Java:
CrmClueVo等*Vo字段上的@ExcelDictFormat(dictType=...)+ExcelDictConvert - 门户:禁止在
crm.py各 export 路由里直接r.get("source")写原始 code - 在
backend/app/utils/crm_export_columns.py定义ExportColumn(..., dict_type="crm_clue_source") - 路由统一调用
export_rows_to_xlsx_response(db, tenant_no=..., columns=..., rows=...) - 工具类:
backend/app/utils/excel_export.py(预加载字典、写 xlsx、StreamingResponse) - 已接入模块:线索、客户、产品、联系人、客户跟进、商机
30. 导出依赖 openpyxl,venv 须显式安装
requirements.txt已声明openpyxl>=3.1.0,但 venv 可能未装 → 导出报No module named 'openpyxl'- 修复:
python3 -m pip install openpyxl --target=backend/venv/lib/python3.9/site-packages或./backend/start.sh --install - 若 venv 从其他机器拷贝导致 pip shebang 失效,用
python3 -m pip安装
31. 前端 Blob 导出须适配 http 拦截器
responseType: 'blob'时,响应是二进制 xlsx,没有 JSONcode字段- 旧逻辑在拦截器里校验
code === 200会导致导出永远失败 - 已在
web-admin/src/utils/http/index.ts集中处理:二进制直返;JSON 错误体(如 500)仍解析报错 request()对 blob 返回res.data,页面直接用Blob下载,勿取.data.data- 导出 API 建议加
showErrorMessage: false,避免与页面ElMessage.error重复
32. CRM 查看详情统一 SystemViewDialog(商机/线索已改)
- 原 CRM
el-drawer宽抽屉 → 门户SystemViewDialog(hero + KV + 可选右侧时间线) - 打开详情前
await dictStore.loadAllDict(),字段用dictStore.getLabel/tagType - 子接口
pageSize遵守后端上限(如跟进列表pageSize: 100,勿传 500)
33. 负责人/用户下拉字段名对齐 fetchUserOptions
- 门户
fetchUserOptions()返回{ label, value }[] - 模板勿写
item.nickName/item.userId(原 CRM 字段名) - 新增表单默认可设
ownerUserId = 当前用户 id
34. 商机模块补充
- DDL/菜单:
docs/sql/incremental_crm_opportunity.sql - 字典兜底:
web-admin/src/utils/crm-opportunity-labels.ts(类型等字典缺失时) - 看板/漏斗/统计路由在
sqxp.ts,菜单未单独配置时可复用crm:opportunity:list winWithContract依赖合同模块,暂未移植