简介面向企业信息化建设人员、产品经理与需求分析初学者这份CRM客户关系管理需求分析设计文档围绕客户关系管理系统的立项与设计展开可用于梳理销售自动化、客户信息整合、数据分析支持等业务场景并为开发团队提供统一的需求基线。压缩包内共1个doc文件约1.66MB内容按引言、任务概述、功能需求、性能需求等章节组织包含用例描述、数据概念结构图与ER图、系统业务流程图等设计材料。已有189人学习下载适合作为CRM项目需求调研、方案撰写与功能拆分时的参考样本。文档对用户组织结构、运行环境、条件与限制及术语定义也有交代读者可据此快速理解从业务目标到功能落地的分析路径并借鉴其章节框架与建模表达方式。1. 一份 60 页的文档就是整套 CRM 的说明书接手一个只留下文档的项目比接手一堆烂代码更难受。上个月我手上就多了这么一份资源一份 60 页的 crm客户关系管理需求分析设计文档版本 1.0密级标着“限制”历史记录里孤零零一行制定记录。没有源码、没有建库脚本、没有原型文件只有目录、用例描述、实体关系图、25 条界面清单。这类东西在客户关系管理项目里太常见了——交付时留下的需求基线后来成了二次开发唯一的依据。它适合两类人要照着文档补出一套可运行 CRM 的后端和接手存量系统、得先搞清角色与数据范围的维护者。下面按我拆它的顺序讲先看骨架再抠权限然后把用例落到表结构最后说几个当年就能躲开的坑。2. 文档骨架拆解六章目录对应哪六种读法拿到一份几十页的 Word最忌讳从第一页顺着读。需求文档的价值密度是极不均匀的引言和参考资料基本是走流程真正的信息集中在功能划分表、用例描述和界面清单三块。我的习惯是先翻目录把章节按“决策信息 / 实现信息 / 验收信息”三类打个标再决定读哪几段。这套文档的六章结构是相当标准的模板引言、任务概述、功能需求、性能需求、运行需求、参考资料。模板本身没什么可讲的可讲的是每一章里真正能拿来干活的东西藏在哪。2.1 六个章节的实际信息密度第 1 章引言里1.1 编写目的和 1.3 术语定义是给评审看的但 1.2 项目背景这四小节值得逐字读用户基本情况、开发目标、用户组织结构、用户相关业务。尤其是“用户组织结构”和“用户相关业务”它们直接决定了后面权限模型长什么样。这套文档里组织结构写的是销售部门、就业部门、系统维护部门三块业务范围列了统一消息管理、工作日志安排、客户分组、客户信息管理、统一邮件平台——这五项基本就是全部功能模块的源头。第 2 章任务概述是技术选型和约束的集中地。2.1 目标里有一句关键的话这套系统“为客户关系管理系统的基础模块提供完善的用户管理和授权管理”并且“通过标准的 WebService 为其他软件系统提供统一的权限管理服务”。这句话的份量比它看起来重得多——它意味着这不是一个孤立的 CRM而是整个平台的身份底座后面所有业务系统都要来调它的鉴权接口。2.2 运行环境给的是当年的服务器配置清单2.3 条件与限制则写了三条硬约束机构管理员只能在自己机构下建用户需要单点登录但不使用任何目录服务“能做成下拉列表的选项一定做成下拉列表”。第 3 章是主体占了全文一多半。3.1 总体功能需求用一张角色协作图讲清三类角色的分工3.2 功能划分用表格把二十多个用例编号和优先级列全3.3 功能描述再逐个展开成用例、实体关系图、业务流程图。第 4 章性能需求只有三小节数据精确度、时间特性、适应性写得比较薄。第 5 章运行需求里最有价值的是 5.2 那一长串界面清单从添加发送短信一直排到客户信息管理。第 6 章参考资料跳过。2.2 功能编号体系从 CRM1.01 到 CRM305 的编码规则3.2 那张功能划分表是我最先抄进笔记的东西。编号看着乱其实规则很清晰第一位数字代表模块大类1 是业务协作类2 是主管专属动作3 是系统管理后面的两位是序号。优先级一列 5 最高标 5 的基本都是核心链路。编号用例名称优先级归属模块备注CRM1.01日程安排5日程日/周/月三层视图CRM1.02日常事务—日程增删改查CRM1.05写邮件5邮件销售与主管共用CRM1.06收件箱5邮件查看/回复/删除/导出/打印CRM1.07废件箱5邮件恢复/永久删除/清空CRM1.14我的审批—审批仅主管CRM1.15我的申请—审批仅业务员CRM2.05指派员工—主管动作主管才能指派CRM3.01客户分类管理4系统管理分类树节点增删改CRM3.02数据库操作5系统管理备份与还原CRM3.03设置用户权限—系统管理管理员专属这张表的用法不是拿来当目录而是当工作量估算和迭代切分的依据。优先级 5 的用例构成最小可用闭环能登录、能管客户、能发邮件、能看日程、能备份。二次开发时我一般先按这张表把接口清单拉出来一个用例至少对应一组 CRUD 接口标 5 的先做。注意编号里有个小坑3.2 表格写的是 CRM114、CRM115 这种连写形式而 3.3 用例正文里写的是 CRM1.03、CRM1.04两种写法指的是同一批用例。做需求追溯矩阵的时候要统一成一种不然对不上号。2.3 非功能需求2009 年的硬件清单今天还能用吗2.2.1 网络及硬件环境那段写得很实在2U 机架式服务器、双路四核 2.66GHz 处理器、2GB 内存、RAID 卡、独立光纤盘柜、SAN 交换机、万转 300GB 硬盘、冗余电源。放在当年这是一套正经的中小企业配置放到今天一台 4 核 8G 的云主机加一块 SSD 就能把同样的原型跑起来数据库和应用的分离部署甚至可以直接合成单机。真正有价值的是 2.2.2 支持软件环境操作系统是那个年代的桌面版 Windows数据库是 2000 年前后那一代商业关系库编译环境 JDK 1.5应用服务器是商用 J2EE 容器 6.1 版。这一套组合决定了代码风格——没有注解驱动的框架没有 Spring Boot事务靠容器管理接口对外暴露走 SOAP 而不是 REST。二次开发如果直接照着这个栈重建会很痛苦稳妥的做法是保留业务语义、换掉技术载体JDK 升到 17、容器换成内嵌 Tomcat、数据库迁到 MySQL 8 或 PostgreSQL 14把 SOAP 接口包一层 REST 门面。第 4 章性能需求的三小节里“数据精确度”和“时间特性”写得比较笼统没有给出具体的响应时间指标和并发量。这是这份文档的短板也意味着二次开发时必须自己补一份非功能基线否则压测阶段没有验收依据容易变成玄学调优。3. 角色与权限模型谁能看谁的客户得在文档阶段就定死CRM 类系统翻车八成不是功能没做出来而是数据看串了。业务员看见同事的客户机构管理员改到别的机构的人主管审批列表里冒出不属于自己部门的申请——这些问题的根都不在代码在需求阶段权限边界没写清。这份文档在这一点上做得比多数同类文档好因为它把权限拆成了“功能权限”和“数据范围”两层。3.1 组织—岗位—用户三层结构与两种管理员的分界线1.3 的术语表先把概念钉住了用户是销售人员或就业部门人员管理员是负责系统管理的人员组织机构是对外机构岗位在系统里表示为工作组。这四个词构成了权限模型的骨架机构下面挂部门部门下面挂岗位岗位上面挂人。系统管理员和机构管理员的差别文档里有一句原文写得很明确系统管理员可以在任何机构下创建用户机构管理员只能在自己机构下新建用户。这句话只写了“新建”没写查询、修改、删除、禁用。这就是典型的文档模糊地带——实现的时候如果只按“新建”做限制接口一旦被构造请求打机构管理员照样能改别人机构的数据。我的处理办法是在设计阶段补一张权限矩阵把每种角色的每个动作都列成格子空格一律填“否”而不是默认放行-- 权限矩阵落库主体 资源 动作 数据范围 CREATE TABLE sys_privilege ( id BIGINT PRIMARY KEY, role_code VARCHAR(32) NOT NULL, -- SALES / SUPERVISOR / ORG_ADMIN / SYS_ADMIN resource VARCHAR(64) NOT NULL, -- crm_customer / crm_mail / sys_user action VARCHAR(16) NOT NULL, -- read / create / update / delete scope_type TINYINT NOT NULL, -- 1 本人 2 本部门 3 本机构及以下 4 全部 UNIQUE KEY uk_role_res_act (role_code, resource, action) );这段 DDL 的关键在scope_type这一列。功能权限能不能点这个菜单和数据范围能看哪些行如果只用一张角色表表达后面必然要在业务代码里到处写 if-else。把范围抽成枚举鉴权拦截器只认这四个值代码会干净很多。UNIQUE KEY是为了防止同一角色同一资源同一动作被重复授权这个坑我在别的项目里踩过——授权表有重复行鉴权时按第一条匹配结果和预期完全相反。3.2 数据范围三档机构、部门、本人SQL 层怎么落文档里散落的业务规则其实已经把范围说清楚了。日程安排那条写的是“销售人员只能对自己的日程安排信息进行查询、添加、修改、删除”我的审批那条写的是“销售主管只能对自己审批的内容进行审批”申请那条写的是“销售人员的申请只能对销售主管进行申请”。三条规则分别对应本人、本人待办、上级审批三种范围。落到实现上最省事也最不容易出错的做法是在服务层统一拼条件而不是让每个 DAO 自己写 where// 按登录人角色拼数据范围条件alias 是主表别名 public String buildScopeClause(LoginUser user, String alias) { switch (user.getRoleCode()) { case SALES: // 业务员只看自己名下的数据 return alias .owner_id ?; case SUPERVISOR: // 主管看本部门含自己名下 return alias .dept_id ?; case ORG_ADMIN: // 机构管理员看本机构及下级 return alias .org_id ?; case SYS_ADMIN: return 1 1; default: // 没有匹配到角色一律拒绝不给默认放行 return 1 0; } }方法体内是拼接用的占位符实际执行时按顺序绑定 userId、deptId、orgId 三个参数不要用字符串拼接真实值。这里最容易翻车的是default分支——很多实现习惯写成放行一旦角色编码改了名或者新加了角色忘了配后果就是全量越权。宁可返回1 0让页面空着也别让数据漏出去。主管范围还有一层隐含逻辑主管本身也是业务员能看到自己的日程和本部门的日程但修改只能改自己的。所以查询用范围条件写操作用归属判断两套判断不能混。文档在“我的审批”用例里写了后置条件“审批只能选择同意或不同意”这其实也是在收窄主管的动作集合——主管对下属的数据是只读加审批不是全权代管。3.3 统一授权接口不用目录服务时单点登录怎么自建2.3 条件与限制里有一句很硬的话用户不需要且不要使用目录服务。2.2.3 又要求单点登录。这两条放在一起等于把“接现成认证中心”这条路堵死了必须自建票据体系面对接其他系统的鉴权。当年这套接口是用 SOAP 暴露的报文结构大致是这样一套语义{ appId: crm-portal, ticket: ST-9f2c1e7a4b8d, action: checkPermission, payload: { userId: 10231, resource: crm_customer, operation: read }, timestamp: 1712300400, sign: md5(appSecrettickettimestamp) }字段含义得说清楚appId标识调用方不同接入系统分配不同密钥ticket是登录后签发的一次性凭证带过期时间action区分是校验登录态还是校验具体权限sign是防重放和防篡改的签名服务端要用同一套规则重算一遍再比对。响应体只需要返回code、message和data.allowed三个关键字段。这套设计的要点在于票据由主系统签发业务系统不存用户表只认票据。好处是用户管理只有一份坏处是主系统一旦挂了全部系统跟着登录不了。所以我一般会加两级兜底——票据本地缓存一份带有效期的登录态主系统不可达时降级为只校验本地缓存同时给票据接口单独做限流避免某个接入系统异常刷爆鉴权服务。文档里 5.4 故障处理及恢复要求那节写得很简略这几条属于必须自己补的。4. 用例到表结构日程、邮件、审批、短信怎么落库3.3.2 里有一张实体—关系图3.3.3 里是一批业务流程图和活动状态图。图在 Word 里是截图看不清细节但结合 3.3.1 的用例正文能把实体和字段反推出来。这一章我按四个业务对象讲落库思路每个都给出可执行的建表语句和几个容易想当然的地方。4.1 客户主数据所有业务对象都靠 customer_id 挂上来文档 5.2.25 单独列了“客户信息管理”这个界面1.2.4 又把客户分组列进了业务范围说明客户是这套系统的主数据。日程的新增弹窗里有关联客户字段日常事务里也有关联客户邮件虽然没有明写但销售给客户发邮件必然要能挂上客户。-- 客户主数据数据范围判断的三个字段都在这里 CREATE TABLE crm_customer ( id BIGINT PRIMARY KEY, cust_name VARCHAR(100) NOT NULL COMMENT 客户名称, cust_level TINYINT NOT NULL COMMENT 分类节点对应 CRM3.01 分类树, org_id BIGINT NOT NULL COMMENT 归属机构, dept_id BIGINT NOT NULL COMMENT 归属部门, owner_id BIGINT NOT NULL COMMENT 归属业务员范围判断主字段, phone VARCHAR(32), create_time DATETIME NOT NULL, del_flag TINYINT NOT NULL DEFAULT 0 COMMENT 0 正常 1 已删, KEY idx_owner (owner_id), KEY idx_dept (dept_id) );三个归属字段org_id、dept_id、owner_id是刻意冗余的。理论上通过owner_id关联用户表就能推出部门和机构但每次列表查询都多一次 join数据量上来以后性能会很难看。冗余的代价是用户调岗时要同步刷客户表——这个动作必须做成一个明确的功能点而不是靠定时任务悄悄跑。我在另一个项目里就吃过这个亏人员调整后客户归属没刷主管的部门视图直接空了一半排查了半天才发现是冗余字段没跟着走。del_flag用逻辑删除而不是物理删除是因为客户下面挂着日程、邮件、审批一堆关联数据物理删除会留一堆孤儿记录。文档 3.2 功能划分里虽然没写客户删除但 5.2.25 客户信息管理界面通常包含这个动作做的时候按逻辑删除处理。4.2 日程的日、周、月三级视图一张表还是三张表3.3.1.1 日程安排那条用例写得很细点“日程安排”页面菜单里有日常事务、日日程、周日程、月日程四项日日程点进去新增弹窗里填主题、起始时间、内容、关联客户周日程是点周日期块月日程点月日期块。三种视图的操作流程几乎一模一样区别只在时间粒度和展示方式。见过不少实现会老老实实建三张表日日程表、周日程表、月日程表。这样做的后果是查询“这个客户相关的所有日程”要 union 三次改字段要改三处。正确的做法是一张表加类型字段-- 日程与日常事务共用一张表靠 schedule_type 区分 CREATE TABLE crm_schedule ( id BIGINT PRIMARY KEY, schedule_type TINYINT NOT NULL COMMENT 2 日日程 3 周日程 4 月日程 9 日常事务, subject VARCHAR(200) NOT NULL COMMENT 主题必填, start_time DATETIME NOT NULL COMMENT 起始时间周/月视图按周月区间切, content TEXT COMMENT 内容, customer_id BIGINT COMMENT 关联客户可为空, owner_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0 未完成 1 已完成, create_time DATETIME NOT NULL, KEY idx_owner_time (owner_id, start_time) );idx_owner_time这个联合索引是给月视图准备的查某人某月的日程条件是owner_id ? AND start_time BETWEEN ? AND ?走这个索引能直接命中区间。周视图和月视图本质上是同一个查询换一个时间区间不需要额外的表或字段。值得注意的是日常事务的处理。文档把日常事务作为日程安排菜单下的第一项但它的语义其实是待办清单和日历上的日/周/月是两种东西。我倾向于共用一张表加类型区分因为两者的字段几乎完全一致分开建表只会增加维护成本。如果后面要加优先级、提醒、重复规则这些待办特有的属性再加字段也不迟。“关联客户”这个字段要允许为空。用例里写的是“关联客户是指日程计划中所涉及的客户信息”但业务员临时记个事不一定挂客户强制必填会让用户绕过系统去用记事本。4.3 审批与邮件状态机定死前端才敢放开按钮审批这块的规则密度是全文档最高的。3.3.1.3 我的审批主管能看到审批列表选中看详情只能选“同意”或“不同意”。3.3.1.4 我的申请业务员添加申请时主题和内容不能为空、必须选一个审批人未通过或未审核的申请可以修改审批通过后不能删除和修改只能查看。这几条合起来就是一个三态机。-- 申请单状态只有 0 待审 / 1 通过 / 2 驳回 CREATE TABLE crm_apply ( id BIGINT PRIMARY KEY, subject VARCHAR(200) NOT NULL COMMENT 主题非空校验在服务层做, content TEXT NOT NULL COMMENT 内容非空校验在服务层做, applicant_id BIGINT NOT NULL COMMENT 申请人, approver_id BIGINT NOT NULL COMMENT 审批人提交时必选, status TINYINT NOT NULL DEFAULT 0 COMMENT 0 待审 1 通过 2 驳回, audit_time DATETIME COMMENT 审批时间, audit_opinion VARCHAR(500) COMMENT 审批意见, create_time DATETIME NOT NULL, KEY idx_approver_status (approver_id, status) );状态机的校验必须放在服务层不能只靠前端把按钮置灰。可编辑的条件是status IN (0, 2)可删除的条件是status IN (0, 2)审批动作要求status 0且当前登录人是approver_id。三个条件任一不满足就抛业务异常。这套判断写在前端只是体验优化写在服务层才是规则本身。邮件是另一个容易想简单的地方。文档的用例写得很细收件箱能查看、回复、删除、导出 Excel、打印发件箱能再次发送废件箱能恢复、永久删除、清空查询邮件单独一个用例还有邮件帐号配置业务规则里反复强调“不同身份登陆看到的邮件不同”。关键就在这句业务规则上。如果把邮件做成一张表靠一个 folder 字段标识在收件箱还是发件箱那么“删除”这个动作就会出问题发件人删掉了已发邮件收件人那边应该还能看到收件人永久删除也不该影响发件人。所以要做到文档要求的恢复、永久删除、清空必须是邮件实体和用户视图分离-- 邮件实体一份内容只存一份 CREATE TABLE crm_mail ( id BIGINT PRIMARY KEY, mail_from VARCHAR(100) NOT NULL, mail_to VARCHAR(500) NOT NULL COMMENT 多个收件人逗号分隔, subject VARCHAR(200), body TEXT, send_time DATETIME, attach_url VARCHAR(500) ); -- 用户视图每个用户对每封邮件各有一条状态 CREATE TABLE crm_mail_user ( id BIGINT PRIMARY KEY, mail_id BIGINT NOT NULL, user_id BIGINT NOT NULL, folder TINYINT NOT NULL COMMENT 1 收件箱 2 发件箱 3 废件箱, read_flag TINYINT NOT NULL DEFAULT 0, UNIQUE KEY uk_mail_user (mail_id, user_id), KEY idx_user_folder (user_id, folder) );分开之后收件人点删除只是把自己那条记录的folder改成 3恢复改回 1永久删除删掉这一行发件箱那边完全不受影响。群发邮件也只存一份实体收件人各生成一条视图记录。查询邮件的用例按 subject、发件人、时间区间过滤直接查crm_mail_user关联crm_mail即可。至于“邮件帐号配置”文档把每个用户的收发件服务器、端口、密码都作为配置项这意味着邮件走的是外部邮件服务器而不是系统内部消息。这一块建议把密码加密存储并且在界面上做连接测试按钮否则用户配错了只能靠一个个发信去试。5. 避坑与排查需求阶段就能埋下的五个雷文档是死的实现是活的。下面五条是我按这套文档做原型时真实遇到过或者提前拦住的问题每条按现象、原因、解决写能省掉不少来回。5.1 权限与数据范围类越权往往发生在“没想到”的地方坑一业务员登录后看到了同事的日程和客户。现象很直观A 登录进去列表里出现了 B 昨天加的日程客户列表里也有 B 名下的客户。原因不是权限配错而是列表查询只按名称模糊匹配压根没加owner_id条件接口参数里还保留了前端传过来的ownerId改一下请求就能查别人。解决分两步列表接口一律不接受前端传的归属人从会话里取拦截器统一注入范围条件DAO 层封掉无条件的全表查询入口。坑二机构管理员能改别的机构的用户。文档只写了“机构管理员可以在自己机构下新建用户”没写改和删。开发按字面实现新建时校验了orgId修改接口直接按主键更新越权的口子就开了。解决是在权限矩阵里把sys_user的create、read、update、delete四个动作全列一遍ORG_ADMIN的scope_type统一填“本机构及以下”修改时先查原记录的org_id再比对比对不上直接拒绝。5.2 数据与流程类状态机和箱体分类最容易想当然坑三审批通过的申请还能被申请人改回去。现象是主管批完了隔天发现内容变了。原因通常是前端把编辑按钮置灰了但接口没做状态校验构造请求照样能改。2.3 里“审批通过后就不能对结果进行删除、修改”这句话是业务规则不是交互建议。解决办法是在服务层的更新方法第一行就查状态status 1直接抛异常同时把“待审和驳回可编辑”写进接口文档让前端有依据做按钮控制。坑四废件箱恢复后收件箱出现两封同样的邮件永久删除还把对方发件箱里的记录一起删了。这个前面讲过根因邮件只有一张表、一个folder字段。多用户共用的数据状态就必须按用户拆。解决是加crm_mail_user视图表删除、恢复、清空全部只操作视图表实体表只在所有视图都删除后才做物理清理。这个改动越早越好等数据跑起来再拆表迁移脚本会写到你怀疑人生。坑五文档里写了“能做成下拉列表一定做成下拉列表”实现成了自由输入脏数据一堆。这条约束藏在 2.2.3 其它要求里一句话带过功能列表里完全没有体现开发很容易漏。等到客户分类、部门、岗位、审批人这些字段全变成手输同一个部门出现五六种写法统计就没法做了。解决办法是把所有枚举型字段抽成字典表前端统一用下拉组件服务端做字典值校验非法值直接拒绝入库。这是典型的“文档里一句话实现里半个月”的需求。坑六单点登录不用目录服务结果票据过期后用户被踢回登录页。这是 3.3 那套自建票据体系的常见问题。票据有效期设得太短用户写一封长邮件就掉线设得太长又担心安全。我的做法是双票据短票据走接口鉴权有效期几分钟长票据存在 Cookie 里用来静默续期只在登录和续期时使用。同时给鉴权接口加本地缓存主系统短时不可用时降级放行已登录用户避免整个平台跟着一起挂。6. 二次开发把需求文档变成能跑的原型我的四步走法这套文档最实际的用法是当作一个技术选型已经过时、业务语义却相当完整的重建蓝图。我的顺序是固定的先做身份和数据范围再做客户主数据然后按优先级 5 的用例补功能最后补非功能。前三步的顺序不能换因为范围条件贯穿所有业务表客户 ID 贯穿所有业务对象先把地基铺错后面每加一个模块都要返工。第一步用 1.3 的术语表和 3.1 的角色图建四张表机构、部门、用户、岗位再把 3.3 的角色编码写进权限矩阵。验证方法是手工构造三种角色的账号用同一个列表接口分别请求比对返回条数。第二步落crm_customer把owner_id、dept_id、org_id三个冗余字段填上跑一遍“业务员只看自己”的用例。第三步按 CRM1.01 日程、CRM1.05 写邮件、CRM1.14 审批的顺序做每个用例做完先自测状态机分支别等功能全做完再测。技术栈上我一般这么替换JDK 升到 17容器换成内嵌 Tomcat数据库迁到 MySQL 8 或 PostgreSQL 14对外接口用 REST 包一层内部保留一份 SOAP 门面兼容老调用方。原来那份 2U 双路服务器的硬件清单可以整体丢掉4 核 8G 单机足够跑通全部用例。改造项文档原方案建议方案验收方式运行环境双路四核 2G 内存 光纤盘柜4 核 8G 云主机 SSD压测 100 并发登录不超时编译环境JDK 1.5JDK 17全量编译零警告数据库2000 年代商业关系库MySQL 8 / PostgreSQL 14迁移脚本可重复执行授权接口SOAP WebServiceREST 保留 SOAP 门面两个入口返回结果一致认证方式自建票据不用目录服务短票据 长票据续期票据过期后能静默续期验证这一步我习惯写个脚本跑一遍关键路径比点页面靠谱# 用三种角色分别请求客户列表比对返回条数是否符合范围预期 for role in sales supervisor org_admin; do token$(curl -s -X POST http://localhost:8080/api/login \ -d account${role}passwordtest123 | jq -r .data.token) total$(curl -s http://localhost:8080/api/customer/list \ -H Authorization: Bearer ${token} | jq .data.total) echo ${role} 可见客户数: ${total} done脚本里jq -r .data.token取的是统一响应体的 token 字段total是分页返回的总条数。预期结果是 sales 的数最小、supervisor 等于本部门、org_admin 最大。三个数字一旦出现相等基本可以断定范围条件没生效。从那以后我每次接这类只有文档没有代码的资源都强制先跑一遍这个三角色比对再动手写业务。文档可以写得漂亮权限不会自己长对。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/31 11:41:54 · 阅读 1.2k 从60页CRM需求文档到可运行原型：权限、表结构与二次开发避坑
简介面向企业信息化建设人员、产品经理与需求分析初学者这份CRM客户关系管理需求分析设计文档围绕客户关系管理系统的立项与设计展开可用于梳理销售自动化、客户信息整合、数据分析支持等业务场景并为开发团队提供统一的需求基线。压缩包内共1个doc文件约1.66MB内容按引言、任务概述、功能需求、性能需求等章节组织包含用例描述、数据概念结构图与ER图、系统业务流程图等设计材料。已有189人学习下载适合作为CRM项目需求调研、方案撰写与功能拆分时的参考样本。文档对用户组织结构、运行环境、条件与限制及术语定义也有交代读者可据此快速理解从业务目标到功能落地的分析路径并借鉴其章节框架与建模表达方式。1. 一份 60 页的文档就是整套 CRM 的说明书接手一个只留下文档的项目比接手一堆烂代码更难受。上个月我手上就多了这么一份资源一份 60 页的 crm客户关系管理需求分析设计文档版本 1.0密级标着“限制”历史记录里孤零零一行制定记录。没有源码、没有建库脚本、没有原型文件只有目录、用例描述、实体关系图、25 条界面清单。这类东西在客户关系管理项目里太常见了——交付时留下的需求基线后来成了二次开发唯一的依据。它适合两类人要照着文档补出一套可运行 CRM 的后端和接手存量系统、得先搞清角色与数据范围的维护者。下面按我拆它的顺序讲先看骨架再抠权限然后把用例落到表结构最后说几个当年就能躲开的坑。2. 文档骨架拆解六章目录对应哪六种读法拿到一份几十页的 Word最忌讳从第一页顺着读。需求文档的价值密度是极不均匀的引言和参考资料基本是走流程真正的信息集中在功能划分表、用例描述和界面清单三块。我的习惯是先翻目录把章节按“决策信息 / 实现信息 / 验收信息”三类打个标再决定读哪几段。这套文档的六章结构是相当标准的模板引言、任务概述、功能需求、性能需求、运行需求、参考资料。模板本身没什么可讲的可讲的是每一章里真正能拿来干活的东西藏在哪。2.1 六个章节的实际信息密度第 1 章引言里1.1 编写目的和 1.3 术语定义是给评审看的但 1.2 项目背景这四小节值得逐字读用户基本情况、开发目标、用户组织结构、用户相关业务。尤其是“用户组织结构”和“用户相关业务”它们直接决定了后面权限模型长什么样。这套文档里组织结构写的是销售部门、就业部门、系统维护部门三块业务范围列了统一消息管理、工作日志安排、客户分组、客户信息管理、统一邮件平台——这五项基本就是全部功能模块的源头。第 2 章任务概述是技术选型和约束的集中地。2.1 目标里有一句关键的话这套系统“为客户关系管理系统的基础模块提供完善的用户管理和授权管理”并且“通过标准的 WebService 为其他软件系统提供统一的权限管理服务”。这句话的份量比它看起来重得多——它意味着这不是一个孤立的 CRM而是整个平台的身份底座后面所有业务系统都要来调它的鉴权接口。2.2 运行环境给的是当年的服务器配置清单2.3 条件与限制则写了三条硬约束机构管理员只能在自己机构下建用户需要单点登录但不使用任何目录服务“能做成下拉列表的选项一定做成下拉列表”。第 3 章是主体占了全文一多半。3.1 总体功能需求用一张角色协作图讲清三类角色的分工3.2 功能划分用表格把二十多个用例编号和优先级列全3.3 功能描述再逐个展开成用例、实体关系图、业务流程图。第 4 章性能需求只有三小节数据精确度、时间特性、适应性写得比较薄。第 5 章运行需求里最有价值的是 5.2 那一长串界面清单从添加发送短信一直排到客户信息管理。第 6 章参考资料跳过。2.2 功能编号体系从 CRM1.01 到 CRM305 的编码规则3.2 那张功能划分表是我最先抄进笔记的东西。编号看着乱其实规则很清晰第一位数字代表模块大类1 是业务协作类2 是主管专属动作3 是系统管理后面的两位是序号。优先级一列 5 最高标 5 的基本都是核心链路。编号用例名称优先级归属模块备注CRM1.01日程安排5日程日/周/月三层视图CRM1.02日常事务—日程增删改查CRM1.05写邮件5邮件销售与主管共用CRM1.06收件箱5邮件查看/回复/删除/导出/打印CRM1.07废件箱5邮件恢复/永久删除/清空CRM1.14我的审批—审批仅主管CRM1.15我的申请—审批仅业务员CRM2.05指派员工—主管动作主管才能指派CRM3.01客户分类管理4系统管理分类树节点增删改CRM3.02数据库操作5系统管理备份与还原CRM3.03设置用户权限—系统管理管理员专属这张表的用法不是拿来当目录而是当工作量估算和迭代切分的依据。优先级 5 的用例构成最小可用闭环能登录、能管客户、能发邮件、能看日程、能备份。二次开发时我一般先按这张表把接口清单拉出来一个用例至少对应一组 CRUD 接口标 5 的先做。注意编号里有个小坑3.2 表格写的是 CRM114、CRM115 这种连写形式而 3.3 用例正文里写的是 CRM1.03、CRM1.04两种写法指的是同一批用例。做需求追溯矩阵的时候要统一成一种不然对不上号。2.3 非功能需求2009 年的硬件清单今天还能用吗2.2.1 网络及硬件环境那段写得很实在2U 机架式服务器、双路四核 2.66GHz 处理器、2GB 内存、RAID 卡、独立光纤盘柜、SAN 交换机、万转 300GB 硬盘、冗余电源。放在当年这是一套正经的中小企业配置放到今天一台 4 核 8G 的云主机加一块 SSD 就能把同样的原型跑起来数据库和应用的分离部署甚至可以直接合成单机。真正有价值的是 2.2.2 支持软件环境操作系统是那个年代的桌面版 Windows数据库是 2000 年前后那一代商业关系库编译环境 JDK 1.5应用服务器是商用 J2EE 容器 6.1 版。这一套组合决定了代码风格——没有注解驱动的框架没有 Spring Boot事务靠容器管理接口对外暴露走 SOAP 而不是 REST。二次开发如果直接照着这个栈重建会很痛苦稳妥的做法是保留业务语义、换掉技术载体JDK 升到 17、容器换成内嵌 Tomcat、数据库迁到 MySQL 8 或 PostgreSQL 14把 SOAP 接口包一层 REST 门面。第 4 章性能需求的三小节里“数据精确度”和“时间特性”写得比较笼统没有给出具体的响应时间指标和并发量。这是这份文档的短板也意味着二次开发时必须自己补一份非功能基线否则压测阶段没有验收依据容易变成玄学调优。3. 角色与权限模型谁能看谁的客户得在文档阶段就定死CRM 类系统翻车八成不是功能没做出来而是数据看串了。业务员看见同事的客户机构管理员改到别的机构的人主管审批列表里冒出不属于自己部门的申请——这些问题的根都不在代码在需求阶段权限边界没写清。这份文档在这一点上做得比多数同类文档好因为它把权限拆成了“功能权限”和“数据范围”两层。3.1 组织—岗位—用户三层结构与两种管理员的分界线1.3 的术语表先把概念钉住了用户是销售人员或就业部门人员管理员是负责系统管理的人员组织机构是对外机构岗位在系统里表示为工作组。这四个词构成了权限模型的骨架机构下面挂部门部门下面挂岗位岗位上面挂人。系统管理员和机构管理员的差别文档里有一句原文写得很明确系统管理员可以在任何机构下创建用户机构管理员只能在自己机构下新建用户。这句话只写了“新建”没写查询、修改、删除、禁用。这就是典型的文档模糊地带——实现的时候如果只按“新建”做限制接口一旦被构造请求打机构管理员照样能改别人机构的数据。我的处理办法是在设计阶段补一张权限矩阵把每种角色的每个动作都列成格子空格一律填“否”而不是默认放行-- 权限矩阵落库主体 资源 动作 数据范围 CREATE TABLE sys_privilege ( id BIGINT PRIMARY KEY, role_code VARCHAR(32) NOT NULL, -- SALES / SUPERVISOR / ORG_ADMIN / SYS_ADMIN resource VARCHAR(64) NOT NULL, -- crm_customer / crm_mail / sys_user action VARCHAR(16) NOT NULL, -- read / create / update / delete scope_type TINYINT NOT NULL, -- 1 本人 2 本部门 3 本机构及以下 4 全部 UNIQUE KEY uk_role_res_act (role_code, resource, action) );这段 DDL 的关键在scope_type这一列。功能权限能不能点这个菜单和数据范围能看哪些行如果只用一张角色表表达后面必然要在业务代码里到处写 if-else。把范围抽成枚举鉴权拦截器只认这四个值代码会干净很多。UNIQUE KEY是为了防止同一角色同一资源同一动作被重复授权这个坑我在别的项目里踩过——授权表有重复行鉴权时按第一条匹配结果和预期完全相反。3.2 数据范围三档机构、部门、本人SQL 层怎么落文档里散落的业务规则其实已经把范围说清楚了。日程安排那条写的是“销售人员只能对自己的日程安排信息进行查询、添加、修改、删除”我的审批那条写的是“销售主管只能对自己审批的内容进行审批”申请那条写的是“销售人员的申请只能对销售主管进行申请”。三条规则分别对应本人、本人待办、上级审批三种范围。落到实现上最省事也最不容易出错的做法是在服务层统一拼条件而不是让每个 DAO 自己写 where// 按登录人角色拼数据范围条件alias 是主表别名 public String buildScopeClause(LoginUser user, String alias) { switch (user.getRoleCode()) { case SALES: // 业务员只看自己名下的数据 return alias .owner_id ?; case SUPERVISOR: // 主管看本部门含自己名下 return alias .dept_id ?; case ORG_ADMIN: // 机构管理员看本机构及下级 return alias .org_id ?; case SYS_ADMIN: return 1 1; default: // 没有匹配到角色一律拒绝不给默认放行 return 1 0; } }方法体内是拼接用的占位符实际执行时按顺序绑定 userId、deptId、orgId 三个参数不要用字符串拼接真实值。这里最容易翻车的是default分支——很多实现习惯写成放行一旦角色编码改了名或者新加了角色忘了配后果就是全量越权。宁可返回1 0让页面空着也别让数据漏出去。主管范围还有一层隐含逻辑主管本身也是业务员能看到自己的日程和本部门的日程但修改只能改自己的。所以查询用范围条件写操作用归属判断两套判断不能混。文档在“我的审批”用例里写了后置条件“审批只能选择同意或不同意”这其实也是在收窄主管的动作集合——主管对下属的数据是只读加审批不是全权代管。3.3 统一授权接口不用目录服务时单点登录怎么自建2.3 条件与限制里有一句很硬的话用户不需要且不要使用目录服务。2.2.3 又要求单点登录。这两条放在一起等于把“接现成认证中心”这条路堵死了必须自建票据体系面对接其他系统的鉴权。当年这套接口是用 SOAP 暴露的报文结构大致是这样一套语义{ appId: crm-portal, ticket: ST-9f2c1e7a4b8d, action: checkPermission, payload: { userId: 10231, resource: crm_customer, operation: read }, timestamp: 1712300400, sign: md5(appSecrettickettimestamp) }字段含义得说清楚appId标识调用方不同接入系统分配不同密钥ticket是登录后签发的一次性凭证带过期时间action区分是校验登录态还是校验具体权限sign是防重放和防篡改的签名服务端要用同一套规则重算一遍再比对。响应体只需要返回code、message和data.allowed三个关键字段。这套设计的要点在于票据由主系统签发业务系统不存用户表只认票据。好处是用户管理只有一份坏处是主系统一旦挂了全部系统跟着登录不了。所以我一般会加两级兜底——票据本地缓存一份带有效期的登录态主系统不可达时降级为只校验本地缓存同时给票据接口单独做限流避免某个接入系统异常刷爆鉴权服务。文档里 5.4 故障处理及恢复要求那节写得很简略这几条属于必须自己补的。4. 用例到表结构日程、邮件、审批、短信怎么落库3.3.2 里有一张实体—关系图3.3.3 里是一批业务流程图和活动状态图。图在 Word 里是截图看不清细节但结合 3.3.1 的用例正文能把实体和字段反推出来。这一章我按四个业务对象讲落库思路每个都给出可执行的建表语句和几个容易想当然的地方。4.1 客户主数据所有业务对象都靠 customer_id 挂上来文档 5.2.25 单独列了“客户信息管理”这个界面1.2.4 又把客户分组列进了业务范围说明客户是这套系统的主数据。日程的新增弹窗里有关联客户字段日常事务里也有关联客户邮件虽然没有明写但销售给客户发邮件必然要能挂上客户。-- 客户主数据数据范围判断的三个字段都在这里 CREATE TABLE crm_customer ( id BIGINT PRIMARY KEY, cust_name VARCHAR(100) NOT NULL COMMENT 客户名称, cust_level TINYINT NOT NULL COMMENT 分类节点对应 CRM3.01 分类树, org_id BIGINT NOT NULL COMMENT 归属机构, dept_id BIGINT NOT NULL COMMENT 归属部门, owner_id BIGINT NOT NULL COMMENT 归属业务员范围判断主字段, phone VARCHAR(32), create_time DATETIME NOT NULL, del_flag TINYINT NOT NULL DEFAULT 0 COMMENT 0 正常 1 已删, KEY idx_owner (owner_id), KEY idx_dept (dept_id) );三个归属字段org_id、dept_id、owner_id是刻意冗余的。理论上通过owner_id关联用户表就能推出部门和机构但每次列表查询都多一次 join数据量上来以后性能会很难看。冗余的代价是用户调岗时要同步刷客户表——这个动作必须做成一个明确的功能点而不是靠定时任务悄悄跑。我在另一个项目里就吃过这个亏人员调整后客户归属没刷主管的部门视图直接空了一半排查了半天才发现是冗余字段没跟着走。del_flag用逻辑删除而不是物理删除是因为客户下面挂着日程、邮件、审批一堆关联数据物理删除会留一堆孤儿记录。文档 3.2 功能划分里虽然没写客户删除但 5.2.25 客户信息管理界面通常包含这个动作做的时候按逻辑删除处理。4.2 日程的日、周、月三级视图一张表还是三张表3.3.1.1 日程安排那条用例写得很细点“日程安排”页面菜单里有日常事务、日日程、周日程、月日程四项日日程点进去新增弹窗里填主题、起始时间、内容、关联客户周日程是点周日期块月日程点月日期块。三种视图的操作流程几乎一模一样区别只在时间粒度和展示方式。见过不少实现会老老实实建三张表日日程表、周日程表、月日程表。这样做的后果是查询“这个客户相关的所有日程”要 union 三次改字段要改三处。正确的做法是一张表加类型字段-- 日程与日常事务共用一张表靠 schedule_type 区分 CREATE TABLE crm_schedule ( id BIGINT PRIMARY KEY, schedule_type TINYINT NOT NULL COMMENT 2 日日程 3 周日程 4 月日程 9 日常事务, subject VARCHAR(200) NOT NULL COMMENT 主题必填, start_time DATETIME NOT NULL COMMENT 起始时间周/月视图按周月区间切, content TEXT COMMENT 内容, customer_id BIGINT COMMENT 关联客户可为空, owner_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0 未完成 1 已完成, create_time DATETIME NOT NULL, KEY idx_owner_time (owner_id, start_time) );idx_owner_time这个联合索引是给月视图准备的查某人某月的日程条件是owner_id ? AND start_time BETWEEN ? AND ?走这个索引能直接命中区间。周视图和月视图本质上是同一个查询换一个时间区间不需要额外的表或字段。值得注意的是日常事务的处理。文档把日常事务作为日程安排菜单下的第一项但它的语义其实是待办清单和日历上的日/周/月是两种东西。我倾向于共用一张表加类型区分因为两者的字段几乎完全一致分开建表只会增加维护成本。如果后面要加优先级、提醒、重复规则这些待办特有的属性再加字段也不迟。“关联客户”这个字段要允许为空。用例里写的是“关联客户是指日程计划中所涉及的客户信息”但业务员临时记个事不一定挂客户强制必填会让用户绕过系统去用记事本。4.3 审批与邮件状态机定死前端才敢放开按钮审批这块的规则密度是全文档最高的。3.3.1.3 我的审批主管能看到审批列表选中看详情只能选“同意”或“不同意”。3.3.1.4 我的申请业务员添加申请时主题和内容不能为空、必须选一个审批人未通过或未审核的申请可以修改审批通过后不能删除和修改只能查看。这几条合起来就是一个三态机。-- 申请单状态只有 0 待审 / 1 通过 / 2 驳回 CREATE TABLE crm_apply ( id BIGINT PRIMARY KEY, subject VARCHAR(200) NOT NULL COMMENT 主题非空校验在服务层做, content TEXT NOT NULL COMMENT 内容非空校验在服务层做, applicant_id BIGINT NOT NULL COMMENT 申请人, approver_id BIGINT NOT NULL COMMENT 审批人提交时必选, status TINYINT NOT NULL DEFAULT 0 COMMENT 0 待审 1 通过 2 驳回, audit_time DATETIME COMMENT 审批时间, audit_opinion VARCHAR(500) COMMENT 审批意见, create_time DATETIME NOT NULL, KEY idx_approver_status (approver_id, status) );状态机的校验必须放在服务层不能只靠前端把按钮置灰。可编辑的条件是status IN (0, 2)可删除的条件是status IN (0, 2)审批动作要求status 0且当前登录人是approver_id。三个条件任一不满足就抛业务异常。这套判断写在前端只是体验优化写在服务层才是规则本身。邮件是另一个容易想简单的地方。文档的用例写得很细收件箱能查看、回复、删除、导出 Excel、打印发件箱能再次发送废件箱能恢复、永久删除、清空查询邮件单独一个用例还有邮件帐号配置业务规则里反复强调“不同身份登陆看到的邮件不同”。关键就在这句业务规则上。如果把邮件做成一张表靠一个 folder 字段标识在收件箱还是发件箱那么“删除”这个动作就会出问题发件人删掉了已发邮件收件人那边应该还能看到收件人永久删除也不该影响发件人。所以要做到文档要求的恢复、永久删除、清空必须是邮件实体和用户视图分离-- 邮件实体一份内容只存一份 CREATE TABLE crm_mail ( id BIGINT PRIMARY KEY, mail_from VARCHAR(100) NOT NULL, mail_to VARCHAR(500) NOT NULL COMMENT 多个收件人逗号分隔, subject VARCHAR(200), body TEXT, send_time DATETIME, attach_url VARCHAR(500) ); -- 用户视图每个用户对每封邮件各有一条状态 CREATE TABLE crm_mail_user ( id BIGINT PRIMARY KEY, mail_id BIGINT NOT NULL, user_id BIGINT NOT NULL, folder TINYINT NOT NULL COMMENT 1 收件箱 2 发件箱 3 废件箱, read_flag TINYINT NOT NULL DEFAULT 0, UNIQUE KEY uk_mail_user (mail_id, user_id), KEY idx_user_folder (user_id, folder) );分开之后收件人点删除只是把自己那条记录的folder改成 3恢复改回 1永久删除删掉这一行发件箱那边完全不受影响。群发邮件也只存一份实体收件人各生成一条视图记录。查询邮件的用例按 subject、发件人、时间区间过滤直接查crm_mail_user关联crm_mail即可。至于“邮件帐号配置”文档把每个用户的收发件服务器、端口、密码都作为配置项这意味着邮件走的是外部邮件服务器而不是系统内部消息。这一块建议把密码加密存储并且在界面上做连接测试按钮否则用户配错了只能靠一个个发信去试。5. 避坑与排查需求阶段就能埋下的五个雷文档是死的实现是活的。下面五条是我按这套文档做原型时真实遇到过或者提前拦住的问题每条按现象、原因、解决写能省掉不少来回。5.1 权限与数据范围类越权往往发生在“没想到”的地方坑一业务员登录后看到了同事的日程和客户。现象很直观A 登录进去列表里出现了 B 昨天加的日程客户列表里也有 B 名下的客户。原因不是权限配错而是列表查询只按名称模糊匹配压根没加owner_id条件接口参数里还保留了前端传过来的ownerId改一下请求就能查别人。解决分两步列表接口一律不接受前端传的归属人从会话里取拦截器统一注入范围条件DAO 层封掉无条件的全表查询入口。坑二机构管理员能改别的机构的用户。文档只写了“机构管理员可以在自己机构下新建用户”没写改和删。开发按字面实现新建时校验了orgId修改接口直接按主键更新越权的口子就开了。解决是在权限矩阵里把sys_user的create、read、update、delete四个动作全列一遍ORG_ADMIN的scope_type统一填“本机构及以下”修改时先查原记录的org_id再比对比对不上直接拒绝。5.2 数据与流程类状态机和箱体分类最容易想当然坑三审批通过的申请还能被申请人改回去。现象是主管批完了隔天发现内容变了。原因通常是前端把编辑按钮置灰了但接口没做状态校验构造请求照样能改。2.3 里“审批通过后就不能对结果进行删除、修改”这句话是业务规则不是交互建议。解决办法是在服务层的更新方法第一行就查状态status 1直接抛异常同时把“待审和驳回可编辑”写进接口文档让前端有依据做按钮控制。坑四废件箱恢复后收件箱出现两封同样的邮件永久删除还把对方发件箱里的记录一起删了。这个前面讲过根因邮件只有一张表、一个folder字段。多用户共用的数据状态就必须按用户拆。解决是加crm_mail_user视图表删除、恢复、清空全部只操作视图表实体表只在所有视图都删除后才做物理清理。这个改动越早越好等数据跑起来再拆表迁移脚本会写到你怀疑人生。坑五文档里写了“能做成下拉列表一定做成下拉列表”实现成了自由输入脏数据一堆。这条约束藏在 2.2.3 其它要求里一句话带过功能列表里完全没有体现开发很容易漏。等到客户分类、部门、岗位、审批人这些字段全变成手输同一个部门出现五六种写法统计就没法做了。解决办法是把所有枚举型字段抽成字典表前端统一用下拉组件服务端做字典值校验非法值直接拒绝入库。这是典型的“文档里一句话实现里半个月”的需求。坑六单点登录不用目录服务结果票据过期后用户被踢回登录页。这是 3.3 那套自建票据体系的常见问题。票据有效期设得太短用户写一封长邮件就掉线设得太长又担心安全。我的做法是双票据短票据走接口鉴权有效期几分钟长票据存在 Cookie 里用来静默续期只在登录和续期时使用。同时给鉴权接口加本地缓存主系统短时不可用时降级放行已登录用户避免整个平台跟着一起挂。6. 二次开发把需求文档变成能跑的原型我的四步走法这套文档最实际的用法是当作一个技术选型已经过时、业务语义却相当完整的重建蓝图。我的顺序是固定的先做身份和数据范围再做客户主数据然后按优先级 5 的用例补功能最后补非功能。前三步的顺序不能换因为范围条件贯穿所有业务表客户 ID 贯穿所有业务对象先把地基铺错后面每加一个模块都要返工。第一步用 1.3 的术语表和 3.1 的角色图建四张表机构、部门、用户、岗位再把 3.3 的角色编码写进权限矩阵。验证方法是手工构造三种角色的账号用同一个列表接口分别请求比对返回条数。第二步落crm_customer把owner_id、dept_id、org_id三个冗余字段填上跑一遍“业务员只看自己”的用例。第三步按 CRM1.01 日程、CRM1.05 写邮件、CRM1.14 审批的顺序做每个用例做完先自测状态机分支别等功能全做完再测。技术栈上我一般这么替换JDK 升到 17容器换成内嵌 Tomcat数据库迁到 MySQL 8 或 PostgreSQL 14对外接口用 REST 包一层内部保留一份 SOAP 门面兼容老调用方。原来那份 2U 双路服务器的硬件清单可以整体丢掉4 核 8G 单机足够跑通全部用例。改造项文档原方案建议方案验收方式运行环境双路四核 2G 内存 光纤盘柜4 核 8G 云主机 SSD压测 100 并发登录不超时编译环境JDK 1.5JDK 17全量编译零警告数据库2000 年代商业关系库MySQL 8 / PostgreSQL 14迁移脚本可重复执行授权接口SOAP WebServiceREST 保留 SOAP 门面两个入口返回结果一致认证方式自建票据不用目录服务短票据 长票据续期票据过期后能静默续期验证这一步我习惯写个脚本跑一遍关键路径比点页面靠谱# 用三种角色分别请求客户列表比对返回条数是否符合范围预期 for role in sales supervisor org_admin; do token$(curl -s -X POST http://localhost:8080/api/login \ -d account${role}passwordtest123 | jq -r .data.token) total$(curl -s http://localhost:8080/api/customer/list \ -H Authorization: Bearer ${token} | jq .data.total) echo ${role} 可见客户数: ${total} done脚本里jq -r .data.token取的是统一响应体的 token 字段total是分页返回的总条数。预期结果是 sales 的数最小、supervisor 等于本部门、org_admin 最大。三个数字一旦出现相等基本可以断定范围条件没生效。从那以后我每次接这类只有文档没有代码的资源都强制先跑一遍这个三角色比对再动手写业务。文档可以写得漂亮权限不会自己长对。希望帮到你。本文还有配套的精品资源点击获取