1. 立项书不是走过场的文档先想清楚它到底在解决什么写这份用户管理系统项目立项书之前我先把一件事摆到桌面上立项书不是写给领导看的仪式感材料。它是一次“提前把坑踩完”的推演——你在这份文档里把边界、代价、风险和三五年后的样子想清楚后面三个月的开发就能少返工两次。我见过太多团队把立项书写成三页 PPT 加一堆形容词评审会上讲得热血沸腾开发到第二个月才发现“账号体系要不要支持多租户”这个问题从没被回答过于是架构推倒重来。所以这篇内容我想讲的是一份能真正指导后续开发的用户管理系统立项书它的骨架长什么样每一节该写到什么颗粒度哪些参数必须提前算哪些话绝对不能写。读者对象是那些被安排“你来牵头搞个用户管理系统”的中高级开发、技术负责人、产品经理也包括刚接手项目管理、手上只有一份模糊需求的新人。基础薄弱的读者也能看懂因为我会把每个术语都用生活化的方式解释一遍并把可直接抄的表格、清单、计算公式给出来。先说清楚这套系统的定位。用户管理系统通俗讲就是一套“谁能进门、进门后能干什么、干了什么要被记住”的底座。它通常包含账号注册与登录、身份认证、角色与权限、组织架构、租户隔离、审计日志、账号生命周期管理这几块。它不像业务系统那样直接产生收入但它是所有业务系统的地基——地基歪一寸上面每一层都要跟着歪。这也是为什么它值得单独立项而不是“顺手在业务代码里加个用户表”了事。1.1 一份立项书的真实读者到底是谁很多人写立项书时默认读者是审批的领导于是通篇讲价值、讲愿景、讲行业趋势。真正读这份文档的人其实分三类而且关注点完全不同。第一类是审批者他关心的是“这事值不值得投人、投多少、什么时候能看到东西、失败了损失多大”。第二类是后续接手的人——架构师、开发、测试、运维他们关心的是“范围到哪、技术约束是什么、有没有历史包袱”。第三类是三五年后的自己或继任者他关心的是“当初为什么这么设计、为什么不选另一条路”。这三类读者决定了立项书必须有两个层次的表达决策层摘要和执行层细节。前者用一页说清楚问题、方案、代价、收益后者用十几页说清楚模块、接口边界、数据模型取向、容量预估、迁移方案。我个人的习惯是把执行层细节放在附录里正文控制在十页以内附录想多长都行。这样领导读得下去开发也查得到东西。还有一个容易被忽略的读者未来的评审者。当你想申请第二期预算、或者想推翻某个设计时立项书就是你唯一的“当初约定”。如果当初写的是“支持灵活的角色配置”而没写清“最多支持几级角色、单用户最多绑定多少个角色”那么后面所有的争论都会变成口水战。所以立项书里凡是能用数字表达的一个形容词都不要留。1.2 用户管理系统为什么值得单独立项有人会问用户管理不就是一张用户表加一个登录接口吗值得单独立项这个问题在系统只有几千用户、单一业务线、没有外部对接的时候答案确实是不值得。但只要出现下面任意一种情况它就必须单独立项账号开始被多个业务系统共用出现外部合作方需要接入出现组织架构调整导致权限需要批量变更出现数据合规要求需要留存操作痕迹出现用户量级从万级跳到百万级。这些情况有个共同点它们都会让“用户管理”从功能变成基础设施。功能可以边写边改基础设施不行。基础设施一旦上线改动成本随接入方数量线性上升。我经历过一次典型的教训早期用户表用了自增主键并且把用户 ID 直接写进了各个业务库的订单表里后来要做账号合并同一个自然人在两个渠道注册了两个账号改造成本远超当初设计一个全局唯一标识的成本。立项书存在的意义就是在成本还低的时候把这些决策定下来。另外用户管理系统往往牵扯到外部依赖比如统一身份认证、短信通道、邮件服务、实名核验。这些依赖的排期不受你控制一旦在开发后期才发现对方要两个月才能开通整个项目就得干等。立项阶段把这些依赖列出来、提前发起流程比任何技术方案都值钱。1.3 立项书和需求文档、技术方案的边界在哪这三个文档经常被混为一谈导致立项书里塞满了字段级设计或者技术方案里反复论证“为什么要做这个项目”。我的划分方式很朴素立项书回答“做不做、做多大、什么时候做完、失败了怎么办”需求文档回答“具体有哪些功能、每个功能的输入输出是什么”技术方案回答“用什么结构实现、为什么这么实现”。按这个划分立项书里出现“用户表包含 id、username、password_hash 三个字段”就是越界了应该写“账号主体需支持唯一标识、登录凭证、可扩展属性三类信息”。反过来需求文档里出现“本项目预计投入六人两个月”也是越界。界划清楚的好处是每份文档都有明确的完成标准——立项书写到“任何一个开发看完能说出这系统大致有几个模块、大概多久能做完、最怕什么”就算合格。我一般会在立项书里放一节“约束与假设”专门记录那些“如果假设不成立方案就要重做”的前提。比如假设“峰值登录请求不超过每秒 300 次”假设“外部认证服务在项目上线前可用”假设“不追溯五年以前的历史数据”。这些假设被白纸黑字写下来后面任何一条被推翻都能立刻触发一次方案复核而不是等出事才发现。2. 立项书骨架拆解每一节该写什么、写到什么颗粒度一份结构完整的用户管理系统立项书我通常按这样的顺序组织项目背景与问题陈述、目标与成功指标、范围界定、干系人与职责、功能模块概览、技术约束与选型取向、里程碑与排期、资源与成本、风险登记、验收标准。这十节里最容易被写废的是前三节和后三节中间几节反而相对好写因为技术人最擅长的就是列模块。下面我按顺序拆解重点讲每一节的“颗粒度红线”——写浅了没用写深了越界。2.1 项目背景与问题陈述用数据说话而不是用形容词背景这一节最常见的失败写法是这样的“随着业务快速发展现有用户体系已无法满足需求亟需建设一套全新的用户管理系统。”这句话的问题不在于语法而在于它什么都没说。什么叫无法满足是性能扛不住、还是功能缺失、还是维护成本太高不同病因对应完全不同的方案把病因模糊掉后面的方案就成了拍脑袋。合格的背景陈述应该包含三样东西现状的具体表现、量化的痛点、不解决会怎样。举个例子我写过的版本是这样的现状问题量化表现影响账号分散在四个业务库同一员工需维护 3 套密码重置工单月均 120 单人力支持成本约每月 40 小时权限靠代码硬编码每次组织调整需改代码并发版平均耗时 3 天组织调整延迟影响业务上线节奏无操作留痕无法回答“谁在什么时候改了这条数据”出现问题只能靠人工回溯平均定位耗时 6 小时用户表无分表设计单表已 480 万行慢查询占比 12%高峰时段登录超时率 3.5%这种表格不需要多漂亮但它能让评审者一眼看出“这些事确实疼”。写这一节时有个小技巧尽量引用系统里能查到的数字比如工单量、慢查询比例、报错率、支持人力投入。数字不需要精确到小数点后两位但必须有出处否则评审时一句“这个数据哪来的”就能把你问住。另外背景里要明确写出“不做会怎样”。很多立项书只讲做了有什么好处不讲不做的代价结果在预算博弈时被一句“能不能明年再说”轻松击穿。不做的代价可以是随着接入方增加改造成本从三个月涨到六个月数据合规检查限期整改某个业务线因权限问题无法上线。把时间窗口讲清楚比讲愿景有效得多。2.2 目标与成功指标把“好用”翻译成可验收的数字目标这一节我见过的最大的坑是把目标写成愿景。“打造统一、高效、安全的用户管理体系”这句话放在年会上讲没问题但放在立项书里它无法验收。验收不了的目标等于没有目标。我的做法是把目标拆成三层业务目标、系统目标、体验目标每一层都绑定指标。业务目标比如“账号统一后密码重置工单量下降 60%”系统目标比如“登录接口 P99 响应时间不超过 200 毫秒峰值 QPS 支撑 500”体验目标比如“新员工从入职到拿到全部系统权限的时间从 2 天缩短到 2 小时”。这三层目标对应不同的验收方式也对应不同的负责人。这里有个经验指标不要超过七个。超过七个说明你还没想清楚哪个最重要评审时也没人记得住。我一般会挑三到五个核心指标做成一张带基线和目标值的表指标当前基线目标值统计方式验收时点登录接口 P99 延迟850 ms≤200 ms压测报告 线上监控上线后 30 天密码重置工单120 单/月≤45 单/月工单系统统计上线后 90 天权限变更平均耗时3 天≤2 小时变更记录时间差上线后 60 天账号数据不一致率约 2%≤0.1%定时对账任务上线后 30 天基线值这一列特别重要。没有基线目标值就是空中楼阁有了基线哪怕目标只提升了 20%也是可衡量的进步。填基线时如果确实拿不到历史数据就诚实地写“暂缺上线前补测”千万不要编。2.3 范围界定写清楚不做什么比写做什么更重要范围这一节我建议用三个清单来组织本期必做、本期不做、未来可能做。“本期不做”这个清单是全篇性价比最高的部分因为它把后续所有的需求插队都挡在了门外。你不写清楚开发到第三周就会有人跑来说“顺便把单点登录也做了吧”而这个“顺便”往往要多花三周。必做清单要写到模块级不要写到字段级。比如“账号生命周期管理注册、激活、冻结、注销”这就够了不需要写“注册时需要哪些字段”。本期不做清单要写理由一句“暂不做”很容易在评审时被追问到崩。我通常这么写多因素认证本期只做密码 一次性验证码的降级方案硬件密钥认证留待下一期理由是当前无强制合规要求且会显著增加终端适配工作量。跨租户数据共享本期采用严格租户隔离理由是跨租户授权模型尚未与业务方达成一致强行实现会导致权限模型反复修改。历史数据全量迁移本期只迁移近两年活跃账号理由是早期数据存在大量重复与脏数据清洗成本高于收益可保留只读查询入口作为过渡。“未来可能做”这一栏不要写太多写多了等于给自己挖坑。一般列三条以内且要标注“需重新评估”——暗示这不是承诺。范围界定还有一条隐性规则凡是不在必做清单里的功能一律默认不做。这句话要写进文档并让所有干系人确认。否则默认状态会变成“你不反对就是同意”最后范围无限膨胀。2.4 干系人与职责找对人比写对字更难用户管理系统有个特点它几乎和所有团队都有交集。业务方要用它登录运维要部署它安全要审它数据团队要它同步客服要处理它的工单。这些人如果立项阶段没被点名开发阶段就会以“我不知道有这个需求”的方式集体出现。我一般会画一张简化的职责表只写四列角色、代表方、在本项目中的职责、决策权限。决策权限这一列是关键要明确写“有否决权”“有建议权”“仅知情”。不写清楚一个接口字段命名都能开会三次。角色代表方职责决策权限项目发起人技术管理层批准预算与范围变更最终决策产品负责人业务产品组需求优先级、验收标准需求范围决策技术负责人平台组架构方案、技术选型技术方案决策安全评审安全组权限模型与数据留存评审安全项否决权运维对接运维组部署方案、容量规划部署方案建议权外部接入方各业务线提供接入需求与联调仅知情这张表填完你会发现有些角色根本没人认领。比如“数据迁移负责人”很多项目到执行阶段才发现没人对历史数据负责。立项阶段把这个坑填上比后面救火便宜十倍。3. 用户管理系统的核心模块与技术选型取向骨架搭好之后立项书里最有技术含量的部分是模块概览与选型取向。注意是“取向”不是“方案”——立项阶段定方向具体实现留给技术方案。但方向定错后面全白搭。下面几块是我认为必须在立项阶段表态的。3.1 账号生命周期与认证体系先把身份这件事定死账号生命周期包括注册、激活、登录、冻结、解冻、注销、归档七个状态。听起来简单但每个状态的转换条件、谁能触发、数据怎么处理都有讲究。立项书里至少要写清楚三件事账号的唯一标识是什么、注销后数据怎么处理、一个自然人能不能有多个账号。唯一标识这件事我的强烈建议是不要用手机号、邮箱或身份证号做主键。这些都可能变而且可能重复一个人两个手机号或者企业场景下一个邮箱对应多个岗位。正确做法是引入一个内部生成的全局唯一 ID所有业务系统引用这个 ID手机号和邮箱只作为可变更的登录凭证。这个决定的成本在立项阶段几乎为零在系统上线两年后可能是一次数月的改造。注销后的数据处理要提前定。常见做法是“逻辑删除 数据脱敏保留”即账号标记为注销、登录凭证清空、业务数据中的关联 ID 保留但不可反查。如果涉及合规要求的留存期还要写明保留多久、到期怎么清理。这一条写不清楚后面法务或安全来问就得临时补方案。认证方式上立项阶段要定的是“主认证方式 兜底方式”。主认证可以是账号密码也可以对接统一认证。兜底方式用于主认证不可用时的人工介入比如管理员重置。这里有个实操经验兜底通道一定要设计限流和审批。我见过一个系统管理员重置密码的接口没有审批也没有频率限制成了事实上的后门。至于凭证形式会话令牌和签名令牌各有取舍。会话令牌服务端可即时失效适合权限变更频繁的场景签名令牌无状态、横向扩展友好但撤销困难。立项书里不用选边但要写下判断依据如果系统里权限变更频率高、且对“立即失效”有硬要求倾向会话令牌如果接入方多、跨域调用多倾向签名令牌配合较短的过期时间和刷新机制。3.2 权限模型RBAC 够用但别忽略数据权限权限模型是用户管理系统里最容易低估的部分。很多人以为权限就是“用户属于角色角色拥有菜单”做到这一层就上线了结果业务方第一周就提出“同样是订单管理员华东区的只能看华东的订单”。这个需求就是数据权限它和功能权限是两个维度。功能权限解决“能不能点这个按钮、能不能调这个接口”数据权限解决“能看到哪些数据”。前者可以用经典的角色-权限模型RBAC覆盖用户表、角色表、权限表、两张关联表五张表打天下。后者就复杂得多常见实现有四种实现方式原理优点代价角色绑定数据范围角色上挂“全部/本部门/本部门及下级/仅本人”实现简单业务方易理解粒度粗组合场景难覆盖规则表达式权限规则写成表达式运行时求值灵活可覆盖复杂场景规则维护成本高易出错数据标签数据打标用户挂标与业务解耦标签维护与同步是长期负担独立授权表逐条记录用户与数据对象的授权关系精确数据量大查询性能压力大立项阶段的建议是先用角色绑定数据范围把接口层预留规则扩展点。也就是说第一版实现最简单的方案但在数据查询层留一个统一的过滤入口未来要升级到规则表达式时不用改所有业务代码。这个“预留”几乎不增加成本但能把未来的改造从“重写”降级为“替换”。还有一个必须提前想的问题权限的继承与冲突。角色有上下级时下级是否自动继承上级权限一个用户同时属于两个角色且权限冲突时是取并集还是取交集这些规则不写清楚开发和测试会各自理解最后线上出现“该看到的看不到、不该看到的看到了”。我的默认取向是功能权限取并集数据权限取最宽范围但涉及敏感操作的权限单独列出白名单必须显式授权。3.3 组织架构与多租户决定未来能不能规模化组织架构这块看起来只是“部门树”但它和权限、审批流、数据归属全都绑在一起。立项书里要明确三件事组织树是单棵还是多棵、组织与账号是强绑定还是弱关联、组织调整时历史数据怎么处理。单棵还是多棵取决于业务形态。单一企业内部用单棵树最简单如果系统要给多个独立主体使用就是多棵树本质上已经是多租户。多租户的隔离级别有三种取向库级隔离每个租户独立库、schema 级隔离、行级隔离共用表加租户字段。三者的取舍很明确隔离级别隔离强度运维成本扩展性适用场景库级最高最高租户多时运维压力大差租户数量少、合规要求高schema 级较高中等中等租户数量中等、需独立备份行级最低最低最好租户数量多、单租户数据量小我的经验是租户数量预期超过三位数就选行级隔离同时在应用层做严格的租户上下文校验任何查询必须带租户条件用统一的中间件强制执行别指望开发自觉。这条规则如果不提前定后面会有开发写出漏掉租户条件的查询造成跨租户数据泄露那是最难排查的一类问题。组织与账号的关联方式我倾向弱关联账号上记录一个“主组织”同时允许通过关联表挂多个组织身份。这样一个人调岗、兼职、跨部门协作都不会导致账号重建。强绑定一个账号一个部门字段实现简单但组织调整时要么改历史数据、要么丢失历史归属两种都不好受。3.4 审计日志与数据合规写进去的每一条都可能被追问审计日志在立项书里经常被一笔带过但它是最容易被安全评审卡住的部分。要写清楚的核心是四件事记什么、记在哪、留多久、谁能看。记什么最低限度是“谁、什么时候、从哪里、对什么对象、做了什么操作、结果如何”。这六个要素缺一不可。很多人只记操作成功不记失败结果排查暴力尝试时毫无线索。我建议登录失败、权限拒绝、敏感数据读取这三类操作必须记录且要比普通操作记更多上下文。记在哪建议独立存储不要和业务库混在一起。原因有两个一是审计日志写入量大混在业务库里会影响业务查询二是审计日志需要防篡改独立存储便于设置只追加权限。常见做法是异步写入独立的日志存储写入链路和业务链路解耦业务侧只负责投递事件。留多久这个要按合规要求来没有明确要求时我一般建议核心操作日志保留一年登录日志保留六个月访问明细保留三个月超期自动归档或清理。这个数字要写进立项书因为存储成本是按这个算出来的。谁能看要区分“系统管理员”和“审计员”。理想情况下这两个角色应该分离系统管理员能改配置但不能看或删审计日志审计员能查日志但不改系统。小团队往往做不到但至少要在文档里写明现状和风险别假装这个问题不存在。3.5 容量预估把“应该够用”换成算出来的数字立项书里最容易被跳过、又最容易被评审追问的就是容量预估。评审者常问的一句是“这个方案能撑多少人”如果回答“应该没问题”基本等于承认没算过。下面是我常用的一套粗略算法可以在立项阶段快速给出量级判断。先定用户规模。假设注册用户 100 万日活比例 10%即 10 万日活。用户的登录行为通常集中在早晚两个高峰假设 20% 的日活发生在早高峰的一小时内即 2 万次登录集中在 3600 秒内平均每秒约 5.6 次。考虑到行为分布不是均匀的峰值系数取 5那么登录接口的峰值 QPS 约 28。这个数字看起来很小但如果登录流程里包含密码哈希校验、图形验证码校验、账号状态查询、权限加载四次串行操作单次登录的耗时就会叠加。密码哈希这里要特别注意。假设使用自适应哈希算法成本参数设到单次校验约 200 毫秒那么单个应用实例的登录处理能力大约是每秒 5 次单核要支撑峰值 28 QPS至少需要 6 个等效并发处理能力再乘上安全冗余系数 2需要 12 个。这个计算直接决定了应用实例数量和扩缩容策略比“多部署几台”靠谱得多。会话存储的容量也值得算。假设同时在线用户 3 万每条会话记录约 2 KB含用户 ID、角色列表、登录时间、设备信息总内存需求约 60 MB。这个量级很小但如果把权限列表全量塞进会话每条涨到 20 KB就是 600 MB再考虑主从复制和持久化开销内存规划就要重新做。所以立项书里要明确“会话中存什么”这直接影响资源预算。审计日志的容量更容易被低估。假设日活 10 万人均每日产生 50 条操作记录每天就是 500 万条。每条记录按 500 字节估算日增约 2.5 GB保留一年约 900 GB加上索引和副本实际存储需求可能在 2 TB 以上。这个数字如果不在立项时算出来运维会在上线三个月后收到磁盘告警然后大家临时讨论“日志能不能只留一个月”而那时安全评审已经通过了“保留一年”的方案。用户主表的增长也要预估。100 万用户单条记录含索引约 1 KB主表约 1 GB这个量级单表完全扛得住。真正的问题在关联表如果每个用户平均关联 8 个角色或权限关系关联表就是 800 万行查询时的连接操作会成为瓶颈。这时候要考虑的是索引设计和缓存策略而不是分库分表。分库分表是千万级用户之后才需要谈的话题过早引入只会让架构复杂度和运维成本翻倍。4. 排期、成本与风险立项书里最容易写虚的三块这三块是立项书的“承诺区”。写得太乐观执行时打脸写得太保守评审通不过。我的原则是排期留缓冲、成本写区间、风险写触发条件。4.1 工作量拆解与排期估算别用“大概两个月”排期估算最忌讳的是给出一个孤零零的数字。一个没有拆解的“两个月”既无法验证也无法在延期时解释。我的做法是先把模块拆到“一个人能在三天内完成”的粒度再逐条估算最后汇总并加缓冲。以用户管理系统为例粗略拆解如下模块主要工作人日估算账号主体表结构、注册、激活、注销、状态机12认证登录、登出、凭证刷新、失败锁定10权限角色管理、权限分配、鉴权中间件15组织架构部门树、人员归属、批量调整10审计日志事件埋点、异步写入、查询界面8管理后台用户列表、批量操作、导入导出15数据迁移清洗脚本、对账、灰度切换12联调与测试接口联调、压测、缺陷修复15上线与观察部署、监控配置、灰度发布6合计103 人日103 人日按三人并行、每人每周有效工作 4 天计算理论工期约 8.6 周。但这是理想值实际还要加上沟通成本、需求澄清、环境等待。我的经验是在理论工期上乘 1.4得到约 12 周。这 40% 的缓冲不是偷懒而是覆盖那些一定会发生但说不清具体是什么的意外。估算方法上我推荐“三点估算”的简化版对每个模块给出乐观值、最可能值、悲观值按乐观 4×最可能 悲观/6 计算期望值。这个方法的好处是逼你思考风险而不是拍一个中位数了事。对于不确定性特别高的模块比如数据迁移直接用悲观值排期因为它几乎总是比预期更麻烦。还有一个排期技巧把外部依赖单独列为一条时间线。短信通道申请、统一认证对接、安全评审排期、域名证书这些都可能有等待期。它们的等待时间不占人力但占日历时间。立项书里画一条并行时间线能避免“代码写完了在等审批”的尴尬。4.2 成本构成人力之外的那些钱立项书里的成本经常只算人力结果上线后发现云资源、第三方服务、合规审计的钱没预算又得走一次审批。我一般把成本分成四块人力、基础设施、第三方服务、隐性成本。人力成本按人日乘以内部核算单价计算这块比较直接。基础设施包括应用实例、数据库、缓存、日志存储、备份要按容量预估的结果倒推。第三方服务包括短信、邮件、实名核验、证书按调用量估算。隐性成本最容易被漏掉比如安全评审的外部费用、数据迁移期间的双系统并行成本、培训与文档成本。给一个量级参考一个支撑十万级日活的用户管理系统基础设施月成本通常在几千到一两万元区间具体取决于是否用托管服务、日志保留多久、是否多可用区部署。第三方短信服务按每条几分钱算日活 10 万里如果有 1% 触发验证码每天 1000 条月成本几十元量级很小。真正贵的是日志存储和备份如果保留一年全量日志并做多副本这部分可能占基础设施成本的一半以上。成本一节建议写成区间而不是单值并说明区间的差异来源。比如“基础设施月成本 8000 至 15000 元差异主要取决于日志保留时长与多可用区部署选择”。这样评审时不会因为一个数字被反复挑战也给了执行时调整的空间。4.3 风险登记表写“可能延期”等于没写风险这一节我见过最敷衍的写法是列一堆“需求变更风险”“人员流动风险”“技术风险”每条后面跟一句“加强沟通”“做好备份”。这种风险表除了占篇幅没有任何作用。有效的风险必须包含四个要素触发条件、影响范围、应对预案、责任人。举个具体的例子对比一下两种写法。敷衍版“数据迁移存在风险可能导致上线延期。”有效版“触发条件历史数据中重复账号占比超过 3%清洗规则无法自动判定归属。影响迁移脚本需人工介入预计增加 8 人日上线推迟一周。预案上线前两周完成全量数据摸底若重复率超过 3%启动人工判定流程同时准备‘只迁移活跃账号’的降级方案。责任人数据迁移负责人。”后一种写法在评审时可能被追问细节但它至少说明你真的想过。而且当风险真的发生时团队不需要从零开始讨论怎么办直接执行预案就行这在赶工期的时候能省下大量决策时间。风险的数量控制在五到八条按“概率 × 影响”排序。概率高影响大的排最前面需要每周跟踪概率低影响小的可以合并成一条“其他风险”。风险登记表不是一次性的立项后每个月应该更新一次状态把已经发生的划掉把新出现的补上。这个习惯坚持下来项目复盘时你会感谢自己。5. 立项评审现场那些一定会被问到的问题立项书写完只是开始真正的考验是评审会。我参加过几十次这类评审问题的高度重复性让我总结出了一份“必问题库”。提前准备好答案比在会上临场发挥靠谱得多。5.1 评审委员会最常问的五个问题第一个问题为什么不买现成的非要自研这个问题几乎必问。回答的关键不是说现成方案多差而是说清楚差异在哪。可以从三个角度切入数据主权账号数据是否必须留在自有系统内、定制深度权限模型是否需要贴合内部组织架构、长期成本按用户规模折算的授权费用与自研维护成本的对比。我建议在立项书里就放一张对比表把“采购、开源改造、完全自研”三条路的人力、周期、可控性、长期维护成本列出来会上直接翻到那一页比口头解释有效十倍。第二个问题为什么需要这么久这个问题考验的是排期的可信度。回答时不要重复总工期而是把关键路径讲清楚哪几个模块是串行的、哪些外部依赖有等待期、缓冲留了多少、缓冲是给什么用的。如果评审者仍然觉得久可以给出“最小可用版本”的裁剪方案说明砍掉哪些模块能提前多久上线以及砍掉之后的风险。这种“有预案的让步”比硬扛更容易通过。第三个问题老系统怎么办数据怎么迁这是用户管理系统立项里最实的一个问题。要回答清楚三件事迁移范围全量还是活跃账号、迁移方式一次性切换还是双写过渡、回滚方案切换失败后多久能退回。我的建议是默认采用“双写 灰度切换”先把新系统的写入接上读流量按比例逐步切过去观察一段时间再完全切换。这个方案的实施成本略高但它把“切换失败”从灾难降级为一次回退操作。第四个问题怎么保证不出数据泄露这个问题通常来自安全评审方。回答要具体到机制而不是态度租户上下文强制校验、敏感字段加密存储、查询接口的权限过滤在数据层而非展示层、审计日志独立存储且只追加、管理后台的敏感操作二次确认、批量导出有审批和限量。把这些写成一张表放进立项书评审时逐条对照说服力很强。第五个问题上线后怎么衡量成功这个问题回到目标与指标那一节。直接翻出指标表说明基线、目标值、统计方式、验收时点。如果评审者追问“如果没达到怎么办”要有一个诚实的回答比如“上线 30 天做首次评估若延迟指标未达标先做索引和缓存优化若仍不达标启动第二阶段的分表方案”。承认可能有第二阶段比拍胸脯保证一次到位更可信。5.2 立项书自查清单在提交评审之前我会用一张清单过一遍。这张清单救过我很多次。检查项合格标准常见问题背景是否有数字至少三个量化痛点全是形容词目标是否可验收每个目标有指标、基线、时点只有愿景范围是否双向有必做清单和明确的不做清单只写做什么干系人是否到人每个角色有具体负责方只写部门不写人容量是否算过有 QPS、存储、增长的估算只写“满足需求”依赖是否列出外部依赖有申请时间和等待期假设随时可用风险是否可执行有触发条件、预案、责任人只有风险名称成本是否分项人力、基础设施、第三方分开只写总数迁移是否有回滚回滚方案和回滚耗时明确只写正向流程术语是否一致全篇同一概念同一叫法账号/用户/账户混用最后一条经常被忽略但它是文档专业度的直接体现。同一个东西一会儿叫“用户”一会儿叫“账户”一会儿叫“账号”读者会以为你在说三样东西。立项书提交前花十分钟统一术语收益很高。6. 常见问题与排查技巧实录这一节讲的是我在实际推进这类项目时踩过的坑。有些坑在立项阶段就能避开有些只有做过一次才知道。6.1 立项阶段最容易翻车的几个场景场景一权限模型没预留数据权限的扩展点。第一版把权限做成“角色-菜单”两级上线三个月后业务方提出按区域看数据结果发现所有查询接口都得改。教训是功能权限和数据权限从第一天就要分开设计哪怕数据权限第一版只实现最简单的“全部/本部门/本人”三档也要有统一的过滤入口。场景二账号唯一性规则没定死导致重复账号。早期允许同一手机号注册多个账号因为手机号不是必填后来做数据合并时发现同一个自然人有四五个账号业务数据散落各处。教训是注册入口必须强校验至少一个唯一凭证且唯一性约束要落在数据库层面不能只靠应用层查重。场景三审计日志写在业务事务里。日志和业务在同一个事务里业务回滚日志也没了而且日志写入失败会导致业务失败。后来改成异步投递业务事务只负责把事件丢进队列日志服务独立消费。代价是日志可能有秒级延迟但可用性大幅提升。场景四组织架构调整没有批量操作。一次组织合并涉及三千多人的部门归属变更后台只能一个个改运维手工操作了两天。立项时如果想到“组织调整是高频操作”就会把批量导入和批量调整放进必做清单。场景五压测只测了登录没测权限校验。登录接口表现很好但因为每个请求都要查一次权限实际业务接口在高峰时响应很慢。教训是压测要覆盖“带权限校验的业务接口”而不是只测最显眼的登录。场景六历史数据没做对账。迁移完成后没有做新旧系统数据对账上线一周后才发现有几千个账号的部门归属丢了。后来补做定时对账任务每天比对总数、关键字段哈希值、抽样明细。对账这件事立项时就该写进必做清单。6.2 问题速查表把上面这些整理成一张排查表方便对着查现象可能原因排查动作登录偶发超时密码哈希成本过高或连接池不足看单次哈希耗时、数据库连接等待权限变更不生效会话缓存未失效检查缓存过期策略与主动失效机制跨租户看到数据查询漏了租户条件全量扫描查询语句加统一拦截账号无法注销业务外键约束梳理关联表改为逻辑删除日志写入拖慢业务同步写入改异步投递独立存储数据迁移后数量对不上清洗规则过滤过多核对清洗前后各状态数量批量操作超时逐条处理改分批提交加进度反馈这张表不是万能的但它能覆盖大部分常见现象。真正遇到问题时最快的定位方法往往不是看日志而是问一句“这个功能最近改过什么”。大部分问题都出在最近的一次变更上。最后分享一个我在立项阶段的小习惯写完立项书之后我会假装自己是一个刚入职、完全不了解背景的开发从头读一遍看能不能只靠这份文档说出“这系统大概有几个模块、哪个最难、最怕什么、什么时候能上线”。如果说不出来说明文档还有含糊的地方回去补。这个自检动作花不了半小时但能让文档的可用性提升一大截。