C# ASP.NET Core 文档管理系统：在线编辑、版本回滚与权限控制

简介：一套基于 C# 与 ASP.NET 构建的 Web 文档管理系统，面向课程设计、毕业设计及中小型团队文档协作场景，重点解决文档在线创建、编辑、存储、共享与权限控制等问题，适合具备一定 C# 基础、希望了解 ASP.NET Web 应用完整实现流程的学习者参考。压缩包共 98 个文件，约 1.31MB，包含 32 个 cs 服务端源码、14 个 aspx 页面、7 个 js 与 4 个 css 前端资源，以及 SQL Server 的 mdf/ldf 数据库文件、sln 解决方案和 csproj 工程文件；另有使用手册、测试分析报告及 jpg/gif 界面素材，便于还原系统结构与运行环境。已有 558 人学习下载。项目将文档管理、在线编辑、角色权限、版本控制和操作日志等能力落在可参考的代码与数据库设计中，适合用来理解 ASP.NET 页面交互、C# 业务逻辑与 SQL Server 存储检索的配合方式，也可作为二次开发或答辩演示的基础工程，对理解系统分层与模块职责较有帮助。

1. 从“存文档”到“改文档”：这套系统真正要解决的那八成工作量

有人拿着课程设计题目来问：文档管理系统不就是建文件夹、上传、下载三件事吗。真动手做才发现，目录树和上传下载加起来只占两成工作量，剩下八成全砸在在线编辑上——两个人同时改一份方案怎么不打架、改到一半浏览器崩了内容还在不在、上周的版本能不能一键回滚、谁能改哪一份文档。这套用 C# 与 ASP.NET Core 搭起来的文档管理系统，重心不在文件存在哪儿，而在“改”这件事怎么被安全地记录下来、怎么被追溯回去。它适合要交一份完整毕设或课程设计的人，也适合要给团队内部做一套轻量文档库的开发者，下面从需求拆解一路写到验收清单，中间该给的代码和配置都给到位。

2. 需求拆解与技术选型：三类角色、四组用例与一套能直接建起来的项目骨架

动手写第一行代码之前，我会强制自己先干一件很枯燥但极省事的事：把角色、用例、页面路由、数据表四者对齐成一张纸。这一步不做，后面必然出现“功能写完了但不知道谁在用”的情况，答辩时被问一句“这个按钮是给谁点的”就哑火。这一章先把角色和用例拆干净，再定技术栈，最后落一套能直接dotnet new出来照着建的骨架。

2.1 先把角色和用例钉死，再谈功能清单

这套系统的角色只有三类，不用设计得更细，细了反而每个角色都不好用。普通成员的动线是：登录后进入自己可见的目录树，能新建、上传、在线编辑自己有写权限的文档，能查看历史版本、能把自己的文档共享给指定的人；部门管理员在此基础上多出目录维护、成员授权、回收站还原与彻底删除；系统管理员只管三件事——账号生命周期、存储配额、全量审计日志，他不应该能看到文档正文。

四组用例决定了整个系统的骨架。文档生命周期组负责新建、上传、重命名、移动、删除、还原，对应的是文档表和文件夹表；在线编辑与协作组负责打开编辑器、自动保存、版本对比、回滚，对应的是文档表和版本表；检索与定位组负责按标题、创建人、时间范围、内容关键字找到文档，对应的是索引字段和查询接口；审计与回收组负责记录谁在什么时候对哪份文档做了什么，对应审计表。每组用例在页面里都要有明确入口，在数据库里都要有明确落点，凡是落不到表的用例，就是需求本身没想清楚。

砍需求比加需求更重要。全文检索引擎不自建，用数据库的模糊匹配加索引字段先撑住，文档量上万再考虑接入外部检索组件；实时协同编辑不做，改为“进入编辑加锁提示和保存前版本校验”，这个折中在毕设场景里完全够用而且讲得清；工作流审批不做，把精力留给版本与权限。我一般会把“不做的三件事”也写进设计文档，评审时反而加分，因为它说明你权衡过，而不是漏掉了。

2.2 技术栈定版：为什么是 C# 加 ASP.NET Core 这一套

选 C# 这条线的核心理由不是语言本身，而是 ASP.NET Core 把几个最容易写歪的东西标准化了：中间件顺序、依赖注入生命周期、授权策略、后台任务宿主。文档系统里“上传要限流、下载要鉴权、转换要排队”这三件事，用框架现成的机制写出来只有几十行，自己搭一套反而容易在细节上出问题。EF Core 的迁移能力对毕设尤其友好，从第一次建表到后期加字段，全部有脚本可查，答辩时把迁移记录一摆，数据库演进过程一目了然。

2.3 分层结构与项目目录：一套可以直接照建的骨架

分层不做成教条，只分四层：Web 层管路由、模型绑定和授权；应用层管用例编排，一个用例一个服务方法；领域层放实体和领域规则，比如“版本号必须连续递增”；基础设施层放数据库上下文、存储实现、转换任务。层与层之间只允许上层调下层，跨层调用一次都不要留，否则一个月后自己都理不清。

# 解决方案目录结构，按职能划分而不是按文件类型划分 DocManager.sln src/ DocManager.Web/ # 控制器、视图、中间件、前端静态资源 Controllers/ Views/ wwwroot/js/editor/ # 在线编辑前端模块 DocManager.Application/ # 用例服务：文档、版本、权限、审计 Documents/ Versions/ Permissions/ DocManager.Domain/ # 实体、枚举、领域异常 DocManager.Infrastructure/ # EF Core 上下文、存储实现、转换任务 Persistence/ Storage/ Conversion/ tests/ DocManager.Tests/ # 版本合并、权限判定的单元测试

启动入口把所有服务一次性注册清楚，注册顺序和生命周期是最容易出错的地方，写的时候顺手加注释，后面改起来不用猜。

// Program.cs：服务注册与中间件顺序 var builder = WebApplication.CreateBuilder(args); builder.Services.AddDbContext<DocDbContext>(opt => opt.UseSqlServer(builder.Configuration.GetConnectionString("DocDb"))); // 存储抽象：默认本地磁盘，将来换对象存储只改这一行 builder.Services.AddSingleton<IStorageProvider, LocalDiskStorageProvider>(); // 授权：文档级 ACL 走自定义 handler，不散落在控制器里 builder.Services.AddScoped<IAuthorizationHandler, DocumentPermissionHandler>(); builder.Services.AddAuthorization(); // 转换任务跑在后台宿主里，避免上传请求被转换耗时拖住 builder.Services.AddHostedService<ConversionWorker>(); builder.Services.AddControllersWithViews(); var app = builder.Build(); app.UseStaticFiles(); // 静态资源要在鉴权之前 app.UseRouting(); app.UseAuthentication(); // 顺序固定：先认证 app.UseAuthorization(); // 再授权 app.MapDefaultControllerRoute(); app.Run();

这段代码里三个参数值得说明：AddDbContext默认作用域生命周期，别改成单例，否则并发请求会共用同一个上下文；AddSingleton用在无状态的存储实现上是安全的，如果存储实现里带了缓存字典，就要换成作用域并考虑并发；UseAuthentication必须排在UseAuthorization前面，反过来写会出现“永远判不出当前用户”的经典问题，排查时日志里一片 401，却怎么都找不到原因。中间件顺序在 ASP.NET Core 里是硬约束，不是风格偏好。

3. 数据模型与权限设计：文档、版本、权限三张核心表怎么撑住整个系统

数据模型定错了，后面所有功能都是在补窟窿。文档系统最容易犯的错是只建一张文档表，把内容、版本、权限全塞进去，写到第三个功能就发现字段互相打架。这一章把核心表结构、版本策略和权限判定三件事拆开讲，每张表都给出可执行的建表语句和取舍理由。

3.1 核心表结构与字段取舍

文件夹用物化路径存，父路径加自身标识拼成一条字符串，查子树用前缀匹配一条语句搞定，比递归查询好维护。文档表只存当前内容与指针，历史内容全部推到版本表。版本表额外存内容哈希，用来做去重和“内容没变就不落版本”的判断。权限表用主体类型加主体标识的写法，既能授权给人，也能授权给部门。

-- 文件夹：物化路径，方便一次查出整棵子树 CREATE TABLE Folders ( Id BIGINT PRIMARY KEY IDENTITY, ParentId BIGINT NULL, Name NVARCHAR(200) NOT NULL, Path NVARCHAR(900) NOT NULL, -- 形如 /1/7/23/ OwnerId BIGINT NOT NULL, CreatedAt DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME() ); CREATE INDEX IX_Folders_Path ON Folders(Path); -- 文档主表：只放当前版本内容与并发控制字段 CREATE TABLE Documents ( Id BIGINT PRIMARY KEY IDENTITY, FolderId BIGINT NOT NULL, Title NVARCHAR(300) NOT NULL, ContentJson NVARCHAR(MAX) NULL, -- 编辑器中间模型 CurrentVersion INT NOT NULL DEFAULT 0, RowVersion ROWVERSION, -- 乐观锁，保存时比对 SizeBytes BIGINT NOT NULL DEFAULT 0, Status TINYINT NOT NULL DEFAULT 1, -- 0草稿 1正常 2回收站 OwnerId BIGINT NOT NULL, UpdatedAt DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME() ); CREATE INDEX IX_Documents_Folder_Status ON Documents(FolderId, Status); -- 版本表：哈希去重 + 快照标记，避免自动保存撑爆表 CREATE TABLE DocumentVersions ( Id BIGINT PRIMARY KEY IDENTITY, DocumentId BIGINT NOT NULL, VersionNo INT NOT NULL, ContentJson NVARCHAR(MAX) NOT NULL, ContentHash CHAR(64) NOT NULL, -- SHA-256，判断内容是否真的变了 IsSnapshot BIT NOT NULL DEFAULT 0, -- 快照版本不可被合并清理 CreatedBy BIGINT NOT NULL, CreatedAt DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME() ); CREATE UNIQUE INDEX UX_Versions_Doc_No ON DocumentVersions(DocumentId, VersionNo); -- 权限表：主体可以是人也可以是部门，Level 越高权限越大 CREATE TABLE DocumentPermissions ( Id BIGINT PRIMARY KEY IDENTITY, DocumentId BIGINT NULL, -- 为空表示这是文件夹级授权 FolderId BIGINT NULL, SubjectType TINYINT NOT NULL, -- 1用户 2部门 SubjectId BIGINT NOT NULL, Level TINYINT NOT NULL, -- 1只读 2可编辑 3可管理 Inherited BIT NOT NULL DEFAULT 1 -- 是否允许向下继承 );

字段取舍上有两处是经验换来的。Documents表里放ContentJson会让单行变宽，但它换来的是“打开文档零额外查询”，在文档系统这种读多写多的场景里划算；如果文档经常超过几兆，就把内容挪到独立的DocumentContents表，用一对一关联，主表保持窄行。RowVersion是数据库自动维护的并发令牌，不要用时间戳代替，毫秒级精度在并发保存下会撞车。

3.2 版本模型：不做全量快照，也不做真正的增量

很多人一听版本管理就想到存 diff。文档编辑器产生的是结构化 JSON，块顺序频繁变动，做真正的文本级增量既复杂又容易在回滚时出错。我一般采用的折中方案是：每次保存都算内容哈希，哈希和上一版相同就直接返回，不落新版本；哈希不同则落一条普通版本；每隔固定次数或固定时间间隔，额外落一条IsSnapshot = 1的快照版本。回滚时从最近的快照加后续版本重放，清理历史时只清非快照版本。

// 版本落库：先比哈希，再决定是否写入，避免自动保存刷出上千条记录 public async Task<int> SaveVersionAsync(long docId, string contentJson, long userId) { var hash = ComputeSha256(contentJson); // 归一化之后再做哈希 var last = await _db.DocumentVersions .Where(v => v.DocumentId == docId) .OrderByDescending(v => v.VersionNo) .FirstOrDefaultAsync(); if (last is not null && last.ContentHash == hash) return last.VersionNo; // 内容没变，直接复用版本号 var nextNo = (last?.VersionNo ?? 0) + 1; var isSnapshot = nextNo % 20 == 0; // 每 20 版落一个快照 _db.DocumentVersions.Add(new DocumentVersion { DocumentId = docId, VersionNo = nextNo, ContentJson = contentJson, ContentHash = hash, IsSnapshot = isSnapshot, CreatedBy = userId }); await _db.SaveChangesAsync(); return nextNo; }

ComputeSha256之前一定要先做归一化：把 JSON 的键排序、去掉空白、把编辑器插入的临时节点剔除。不做归一化，同一份内容因为键顺序不同就会算出两个哈希，去重等于没做。快照间隔的 20 是个可调参数，文档改动频繁就调小，存储紧张就调大，一般 10 到 30 之间都合理。

3.3 权限：从角色到文档级 ACL 的判定链路

只用角色做权限，在文档系统里一定会不够用，因为总有人要“把这一份文档单独共享给某个同事”。做法是在角色之上加一层资源级授权，判定时从文档自身向上沿文件夹路径逐级查找显式授权，最近的一级优先，路径上出现显式拒绝就直接拒绝。

// 计算用户在某个文档上的最终权限级别 public async Task<PermissionLevel> GetEffectiveLevelAsync(long docId, long userId) { var doc = await _db.Documents.FindAsync(docId); var folderPath = await GetFolderPathAsync(doc.FolderId); // 形如 /1/7/23/ // 1. 文档级显式授权优先级最高 var docLevel = await _db.DocumentPermissions .Where(p => p.DocumentId == docId && p.SubjectType == 1 && p.SubjectId == userId) .Select(p => (PermissionLevel?)p.Level).FirstOrDefaultAsync(); if (docLevel.HasValue) return docLevel.Value; // 2. 沿文件夹路径自近向远查找，最近一级生效 foreach (var folderId in ParsePathReversed(folderPath)) { var level = await _db.DocumentPermissions .Where(p => p.FolderId == folderId && p.SubjectType == 1 && p.SubjectId == userId) .Select(p => (PermissionLevel?)p.Level).FirstOrDefaultAsync(); if (level.HasValue) return level.Value; } // 3. 都没有命中，落到角色默认权限：本人创建的可编辑，其余只读 return doc.OwnerId == userId ? PermissionLevel.Edit : PermissionLevel.Read; }

这段逻辑的关键在于“最近一级生效”和“本人创建兜底”这两条规则。实际写的时候容易漏掉部门授权，主体类型等于 2 时要先查出用户所属部门再匹配一次，否则共享给整个部门的功能形同虚设。权限判定不要在控制器里 if-else 拼，全部收进一个IAuthorizationHandler，下载、预览、编辑、删除四个入口复用同一份判定，越权漏洞基本就堵住了。

4. 在线编辑模块落地：文档中间模型、自动保存与冲突处理

在线编辑是这套系统的重心，也是最容易做成“看起来能打字、实际不能用”的模块。很多课程设计里的编辑器就是一个大textarea，提交时把纯文本塞进数据库，导出之后排版全丢。要做得能拿得出手，得先把文档中间模型定下来，再把自动保存和冲突处理这两条链路打通。

4.1 文档中间模型：把文档拆成可存储、可校验的块

不直接存 HTML，是因为 HTML 里样式和结构混在一起，做版本对比几乎不可能，做权限控制也无从下手。折中方案是存一份块模型 JSON：文档由若干块组成，每块有类型和属性，正文内容作为块的内容字段。段落、标题、列表、表格、图片、引用这六种块足够覆盖绝大多数办公文档。

{ "version": 1, "blocks": [ { "id": "b1", "type": "heading", "level": 2, "text": "季度工作说明" }, { "id": "b2", "type": "paragraph", "text": "本季度重点推进三件事。", "marks": [] }, { "id": "b3", "type": "list", "ordered": false, "items": ["完成文档迁移", "补齐权限配置", "整理历史版本"] }, { "id": "b4", "type": "image", "fileId": "f_2024_a1", "width": 640 } ] }

这份模型带来三个直接好处：渲染时服务端和前端各写一个渲染器，输出结果一致；版本对比按块 id 做差异，能精确定位“哪一段被改了”；导出 docx 时块类型可以直接映射到文档元素，不用反向解析 HTML。块的 id 在创建时生成，编辑过程中不变，这是后面做冲突提示的基础。

4.2 自动保存与乐观锁：一次保存请求的完整链路

前端在停止输入后延迟三秒触发保存，请求里带上当前文档的版本号作为基准。服务端用RowVersion做条件更新，影响行数为零就说明期间有人先保存了，返回 409 让前端提示用户。

// 保存接口：条件更新实现乐观锁，冲突时返回 409 而不是覆盖 [HttpPost("/api/documents/{id:long}/save")] public async Task<IActionResult> Save(long id, [FromBody] SaveRequest req) { var affected = await _db.Documents .Where(d => d.Id == id && d.RowVersion == req.BaseRowVersion) .ExecuteUpdateAsync(s => s .SetProperty(d => d.ContentJson, req.ContentJson) .SetProperty(d => d.UpdatedAt, DateTime.UtcNow)); if (affected == 0) return Conflict(new { code = "VERSION_CONFLICT", latestVersion = await GetLatestAsync(id) }); var versionNo = await _versions.SaveVersionAsync(id, req.ContentJson, CurrentUserId); return Ok(new { version = versionNo }); }

BaseRowVersion是前端打开文档时拿到的并发令牌，从加载接口返回，不要用前端自己维护的计数代替。ExecuteUpdateAsync直接生成一条带条件的 UPDATE，不存在“先查后改”的竞态窗口，比自己写比较逻辑可靠。返回 409 之后前端不要简单地弹个框就完事，正确做法是把服务端最新内容拉回来，做一次块级差异比对，把有冲突的块标红让用户手动选，这个体验差别在答辩演示时非常明显。

// 前端自动保存：防抖 + 冲突后重载差异 let saveTimer = null; let baseRowVersion = null; function scheduleSave(contentJson) { clearTimeout(saveTimer); saveTimer = setTimeout(() => doSave(contentJson), 3000); } async function doSave(contentJson) { const resp = await fetch(`/api/documents/${docId}/save`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ contentJson, baseRowVersion }) }); if (resp.status === 409) { const data = await resp.json(); renderConflictDiff(data.latestVersion); // 标记冲突块，等待用户选择保留哪一版 return; } const ok = await resp.json(); baseRowVersion = ok.rowVersion; // 更新令牌，下一次保存继续用 }

这里有个细节值得提前想清楚：防抖时间设成三秒不是随便定的，设成一秒会让网络请求数量翻好几倍，设成十秒又容易在切页面时丢内容。三到五秒是经验区间，同时再补一个“页面可见性变化时立即保存”的监听，浏览器切后台或关闭前把最后一份内容送出去，这条兜底比调参数更管用。

4.3 附件与在线预览：转换任务怎么排进后台

上传的 docx 想在浏览器里直接看，需要转换成 HTML。转换是 CPU 密集且耗时的操作，绝不能放在上传请求里同步做，否则一个几十兆的文档就能把请求线程占住。做法是上传完成后把文档标识写入任务队列表，由后台托管服务轮询消费。

// 后台转换任务：取任务、转换、写回结果，失败标记可重试 public class ConversionWorker : BackgroundService { protected override async Task ExecuteAsync(CancellationToken token) { while (!token.IsCancellationRequested) { using var scope = _scopeFactory.CreateScope(); // 后台任务必须自建作用域 var queue = scope.ServiceProvider.GetRequiredService<IConversionQueue>(); var job = await queue.DequeueAsync(token); if (job is null) { await Task.Delay(2000, token); continue; } try { var html = await _converter.ToHtmlAsync(job.FilePath); await queue.MarkDoneAsync(job.Id, html); } catch (Exception ex) { await queue.MarkFailedAsync(job.Id, ex.Message, retryAfter: 3); } } } }

后台服务里必须自己创建作用域，这是踩过一次才记住的点：BackgroundService是单例，直接注入作用域的数据库上下文会在第一次迭代之后一直复用同一个实例，跑久了就出现跟踪实体异常。重试次数给三次，超过就标记为永久失败并把原始文件保留，让用户能下载原件，这比反复重试把队列堵死要体面得多。

5. 避坑与排查：五个最容易在上线前翻车的点

前面几章写的是“应该怎么做”，这一章写“做完了为什么还是不对”。这五条都是我在类似系统里真实遇到过的，按现象、原因、解决三段说清楚，照着排查基本能覆盖八成故障。

5.1 上传稍大的文档就报 413 或者进程内存暴涨

现象是本地传 5MB 的文档没事，传 50MB 直接返回 413，或者服务器内存曲线陡增之后接口超时。原因通常有两层：框架默认对请求体大小有上限，超过就直接拒绝；同时代码里习惯性地把上传流全部读进MemoryStream再写盘，一个并发上传就能吃掉几百兆。解决分两步，先在配置里显式放开请求体限制并把单次请求上限控制住，再把写盘改成流式复制。

// 放开请求体限制，同时用流式写入避免整块进内存 [HttpPost("/api/files/upload")] [RequestSizeLimit(200 * 1024 * 1024)] // 单请求上限 200MB [RequestFormLimits(MultipartBodyLengthLimit = 200 * 1024 * 1024)] public async Task<IActionResult> Upload(IFormFile file) { var target = _storage.ResolvePath(file.FileName); await using var input = file.OpenReadStream(); // 不读进内存 await using var output = System.IO.File.Create(target); await input.CopyToAsync(output); // 流式落盘 return Ok(new { fileId = await _storage.RegisterAsync(target, file.Length) }); }

RequestSizeLimit和RequestFormLimits两个都要加，前者管整体请求体，后者管表单分段，只加一个仍然会在某些客户端上报 413。如果前置了反向代理，还要在代理层同步调整上限，否则请求根本到不了应用。

5.2 编辑一小时后，版本表里多了上千条记录

现象是打开版本历史面板卡住，数据库体积涨得离谱。原因是每次自动保存无条件插一条版本，用户敲一个字就存一次，一小时下来几百上千条很正常。解决思路是三层过滤：内容哈希相同直接跳过；五秒内的连续保存合并成一条；按固定间隔落快照，清理时只清非快照版本。第一层在服务端做，第二层在保存接口入口做，用文档标识加时间窗判断，第三层就是 3.2 里那段快照逻辑。清理任务要放在后台，别在用户操作路径上跑删除。

5.3 两个人同时编辑，后保存的把先保存的覆盖了

现象很隐蔽，用户不会立刻发现，等看到内容少了才来报。原因是没有并发控制，两个请求都执行了无条件 UPDATE，后到的覆盖先到的。解决就是把版本号或行版本令牌带进 WHERE 条件，影响行数为零返回 409，前端拉最新内容做块级比对。这里有个反直觉的点：光加锁不够，锁只能拦住同时提交，拦不住“A 打开后去开会，B 改完，A 回来继续改”这种长事务场景，所以冲突提示一定要做成能合并的界面，而不是简单弹一个“保存失败”。

5.4 权限判断写在控制器里，越写越乱最后漏判

现象是某个下载接口忘了加判断，用户改一下地址栏的文档 ID 就能拿到别人的文件。原因是权限逻辑散落在各个 action 里，加一个入口就要记一次，早晚会漏。解决是把判定收进统一的授权处理器，所有涉及文档的入口走同一套策略，下载链接用短时效的签名令牌而不是直接暴露物理路径。

// 下载走一次性签名令牌，避免直接暴露文件路径 public string BuildDownloadToken(long docId, long userId, TimeSpan ttl) { var payload = $"{docId}:{userId}:{DateTimeOffset.UtcNow.Add(ttl).ToUnixTimeSeconds()}"; var sig = Convert.ToBase64String(_hmac.ComputeHash(Encoding.UTF8.GetBytes(payload))); return $"{Convert.ToBase64String(Encoding.UTF8.GetBytes(payload))}.{sig}"; }

令牌有效期给五分钟足够，签名用服务端密钥，校验时先验签再验过期，两步都不能省。

5.5 文档内容原样输出，粘贴进来的脚本被执行了

现象是某份从别处粘贴过来的文档一打开就弹窗或者页面错乱。原因是富文本内容在保存时没做过滤，渲染时又直接输出到页面。解决分两道：服务端保存前对块模型做白名单校验，只允许预定义的块类型和有限的样式属性；渲染层统一走自己写的渲染器，不使用原样插入 HTML 的方式，同时在响应头加一条内容安全策略兜底。白名单要写死成常量表，别用黑名单，黑名单永远补不全。

6. 验收与答辩：用一份十二项清单把系统讲成一套完整方案

到了这一步，功能写完了，真正决定评价的是你能不能在三十分钟里证明它跑得通。我的习惯是准备一份固定的验收清单，从空数据库开始，一条一条走，走不通的那条就是答辩会被追问的那条。清单不要写“测试权限功能”这种模糊项，每一项都要能落到具体操作和具体结果。

这十二项覆盖了存储、编辑、并发、权限、安全、回收、审计七条主线，正好对应前面几章的设计。演示顺序建议按表走，不要临时挑功能点，因为评审最想看的恰恰是“边界情况你怎么处理”，第 5、6、9、10 四项是加分项，主动演示比被问出来强得多。

答辩陈述控制在八分钟：两分钟讲需求和为什么不做全文检索、不做实时协同；三分钟讲数据模型，把文档表、版本表、权限表画在白板上讲清关系；两分钟现场跑清单里的第 4、6、9 项；剩下一分钟讲你知道的不足和下一步怎么改。主动说不足比被问出来体面，比如“并发冲突目前是块级提示，还没做到字符级合并”，这句话说出来，评审通常会点头而不是继续追问。

从那以后我每次带人做这类系统，演示前都强制自己清空数据库、换个没登录过的浏览器，按清单从注册开始重走一遍，不看代码、不连开发环境，只当自己是第一次用的用户。走不通的那一步，往往就是评审第一个会点的地方。希望帮到你。

本文还有配套的精品资源，点击获取