简介：一份面向ASP.NET开发者的企业公文流转系统完整源码，旨在通过Web化审批流程，提升组织内部的办文效率。项目覆盖Asp.Net框架、工作流设计、数据库管理、身份验证与权限控制等核心知识，适合正在学习企业级Web开发的初学者或需要搭建OA雏形的技术人员参考。
包体共91个文件，以C#源代码、ASPX页面、GIF图标等为主，并包含SQL建表脚本以及MDF/LDF数据库文件，可直接还原附带演示数据；其中GIF、JPG主要用作界面图标与图片素材，SQL脚本负责建表及初始化数据，web.config等文件用于配置部署环境。压缩包仅145KB，便于快速下载解压。
已有226人点击学习，侧面说明该示例具备一定参考价值。通过源码可了解公文列表展示、文件提交与审批、用户及角色管理等模块的实现思路，既能作为课程设计的基础框架，也能为后续扩展工作流、邮件通知、报表统计等功能提供入手点。
1. 拿到一套Asp.net公文流转源码，第一步不是改代码而是划边界
前阵子单位信息科的老同事把一套Asp.net公文流转系统源码丢给我，说“给你参考参考”。我解压完一看，aspx页面一大堆，数据库脚本也有，但第一反应不是打开Visual Studio，而是先把需求边界想清楚。很多人拿到这类源码翻车，不是因为代码差，而是根本没搞明白公文流转系统到底要解决什么问题，结果照着改了一个月，改出来的东西既不像公文系统，连OA都算不上。
公文流转和普通CRUD管理系统的区别，说白了就一句话：普通系统管的是“数据”，公文系统管的是“状态”。一篇公文从起草、部门审核、领导签发、编号盖章、分发传阅、到归档销毁，重点是文件在每个节点经历了什么、谁经手、什么时间做了什么动作、能不能退回重走。数据反而简单，就是标题、主送机关、正文、附件这些字段。所以当你评估一套源码值不值得用，先别看界面多好看，先看它的状态流转模型做得到不到位。
把范围再收窄一点，一套能落地使用的公文流转系统，至少要覆盖四条业务主线：
- 发文流程：拟稿人起草 → 部门负责人核稿 → 会签部门会签 → 领导签发 → 文号管理 → 套红盖章 → 分发。
- 收文流程：登记收文 → 办公室主任拟办 → 领导批示 → 承办部门办理 → 反馈 → 归档。
- 签报/请示流程：类似于发文的轻量版本，速度快、环节少。
- 档案关联：公文办结以后要自动关联到档案模块，按年度、文号、密级归档，能查能导。
这四条主线里，发文和收文是骨架，签报是变体，归档是收尾。我拿到源码第一件事就是把代码里对应的模块找出来，看它覆盖了几条。很多Asp.net老源码只做了收发文登记和简单的列表查询，流程靠数据库字段硬改，比如每级审批人设置一个字段，这种系统稍微调一下流程就要改表，后面维护成本极高，趁早放弃。
2. 从源码里看清架构：为什么我劝你先看项目结构而不是看页面
2.1 Asp.net项目的两种典型组织方式
公文流转源码的年代跨度很大，Visual Studio里常见的Asp.net项目有两类组织方式。一类是老的Web Application / Web Site，aspx页面直接堆在根目录，App_Code里放公共类，数据访问用SqlConnection加SqlCommand写在页面后台代码里。另一类是相对现代的MVC模式，按Models、Views、Controllers分目录，数据访问用EF或Dapper。
我个人的判断标准很简单：如果源码里80%的页面后台代码是Page_Load里面连着写几十行SQL拼字符串，这个项目的中长期维护成本基本是灾难。倒不是说不能用，而是公文系统的流程逻辑本来就很绕，业务逻辑和页面耦合太紧，后面加一个环节就要动好几个页面，改完还容易把别的功能带崩。
拿到源码以后，我建议先画一张项目的分层图：哪一层是页面展示，哪一层是业务逻辑，哪一层是数据访问。标准做法是四层：表现层（aspx或Controller）、业务逻辑层（处理流程流转、校验、权限判断）、数据访问层（封装SQL或ORM操作）、以及通用的工具类和实体类。四层之间必须单向依赖，表现层只调业务层，业务层只调数据访问层。如果源码不是这样的结构，二次开发时你就要留个心眼，先想清楚哪些地方需要补业务层，而不是直接在aspx里塞代码。
2.2 数据访问方式决定了你的改造工作量
翻代码的时候重点看数据访问层的写法。我看到的老公文系统有两种典型做法：一种是SqlHelper封装，到处是CommandType.Text的拼接SQL，参数拼接用字符串加起来，这种代码安全性隐患很大，稍不小心就出SQL注入漏洞；另一种是用了存储过程，流程提交、退回、查询都走存储过程，这种相对好一点，至少数据库迁移时逻辑还在。新一些的源码用EF或Dapper，可读性和可维护性明显好一个档次。
这里说个我踩过的坑。有次我拿到一套看起来功能齐全的源码，数据库脚本也能正常执行，结果一跟踪发现所有列表查询都是三层嵌套循环在内存里做的条件过滤，数据量小的时候没感觉，等公文量积累到几万条，列表打开要十几秒。这类问题在源码评估阶段不容易发现，我的办法是看分页是怎么实现的，如果列表没有数据库分页，而是DataTable.Select或者循环遍历，趁早换一套。
3. 数据库设计才是这套系统的胜负手
3.1 核心表的划分逻辑
公文系统的数据库表看着很多，其实认准几条线就不会乱。第一类是组织机构基础表，包括部门表、员工表、角色表、员工角色关联表；第二类是公文业务表，包括公文主表、正文内容表、附件表、文号表；第三类是流程表，这是重点，包括流程实例表、流程节点表、审批记录表（也叫流转记录表）。
我看到不少Asp.net老源码的问题出在第二类和第三类混在一起。比如审批记录就直接在公文主表上建字段，比如“处长审批意见”一列、“主任审批意见”一列、“领导审批意见”一列，流程固定三个节点就建三个列，加一个环节就要加列。这种设计的出发点是为了查询方便，但完全丧失了灵活性。正规做法是审批意见单独建表，主表只有当前状态和当前处理人，每次操作往审批记录表插一行，既能完整回溯历史，又能支持任意数量的节点。
3.2 流程相关表的设计参考
我在实际二次开发里常用的表结构大概是这样的。流程实例表存一次具体流转的当前信息：
CREATE TABLE FlowInstance ( InstanceId INT IDENTITY PRIMARY KEY, DocId INT NOT NULL, -- 关联公文主表 FlowType VARCHAR(20) NOT NULL, -- 发文/收文/签报 CurrentNodeId INT NOT NULL, -- 当前所在节点 CurrentUserId INT NOT NULL, -- 当前待办人 FlowStatus TINYINT NOT NULL, -- 0草稿 1流转中 2已办结 3已退回 4已终止 StartTime DATETIME NOT NULL, EndTime DATETIME NULL );审批记录表存每一笔操作的历史轨迹：
CREATE TABLE FlowLog ( LogId INT IDENTITY PRIMARY KEY, InstanceId INT NOT NULL, NodeId INT NOT NULL, -- 操作节点 OperatorId INT NOT NULL, -- 操作人 ActionType TINYINT NOT NULL, -- 1提交 2同意 3退回 4会签 5转办 6终止 Comment NVARCHAR(500) NULL, -- 审批意见 OperateTime DATETIME NOT NULL DEFAULT GETDATE() );这两张表是流程引擎的基石。有了FlowLog，你想查“某篇公文的完整流转轨迹”“某人经手过哪些待办”“某节点平均耗时多久”都能通过简单的SQL查到，而且业务代码完全不用改。我在改造老系统时最常做的事就是把原来散落在多个字段里的审批信息迁移进FlowLog，迁移完成后整个系统的流程追踪能力立刻上一个台阶。
4. 工作流这部分才是核心：状态机、回退、会签、转办
4.1 用状态机的思路理解流程流转
公文流转的本质是一个有限状态机。公文在任意时刻处于某个状态，用户的操作触发状态迁移，迁移过程校验权限和前置条件，迁移完成后更新状态和待办人。把流程理解为状态机之后，代码就清晰了。Asp.net的页面层只做一件事：接收用户的动作按钮，把动作参数传给工作流处理层，由处理层统一判断能不能走下一步。
我一般定义一个流程操作服务，类似这样的伪代码：
public FlowResult Execute(FlowAction action) { // 1. 加载流程实例和公文实体 var instance = _flowRepository.GetInstance(action.InstanceId); var doc = _docRepository.GetById(instance.DocId); // 2. 校验当前操作人是否有权处理该节点 if (instance.CurrentUserId != action.OperatorId) return FlowResult.Fail("当前用户不是待办人"); // 3. 根据动作类型决定走哪个状态迁移方法 switch (action.ActionType) { case ActionType.Submit: return Submit(instance, doc, action); case ActionType.Agree: return MoveToNext(instance, doc, action); case ActionType.Return: return ReturnToPrevious(instance, doc, action); case ActionType.CounterSign: return CounterSign(instance, doc, action); case ActionType.Transfer: return Transfer(instance, doc, action); } }4.2 退回逻辑为什么是难点
公文系统的流程危险品类不少，最考验设计水平的是退回。退回分两种：一种是退回给上一个处理人，这叫逐级退回；一种是退回到拟稿人重新修改，这叫退回报文。还有更复杂的，领导在最后一步签发时觉得前面某部门意见不够充分，要求退回到那个部门重新会签。
市面上很多Asp.net老源码的退回就是简单地把CurrentUserId改回上一个人的Id，根本不记录退回原因和目标节点。这样操作看似简单，但一旦流程链条较长，退回后目标人不清楚改哪里，而且追溯时看不到“谁在什么时候因为什么原因退回”，最后必然扯皮。我的做法是在FlowLog里记录目标节点和目标人，退回操作本身也生成一条日志，同时在公文的显著位置展示最近一次退回意见。
会签是另一个常见难点。会签的意思是多个部门同时审批，所有人都同意才进入下一步。最简单的实现是用一个计数器：会签节点启动时初始化会签人员列表和总人数，每收到一个同意意见就把已完成数加一，当已完成数等于总人数时自动推进到下一个节点。这里有个细节要注意，如果有人填写了“不同意”，流程应该直接终止或者退回主办部门，而不是傻等其他人继续签。这些逻辑都要在状态机里明确分支。
4.3 转办与委托：容易被忽略的隐藏需求
转办是A把当前待办转给B处理，委托是A出差前把自己的所有待办暂时授权给B处理。公文系统上线后，用户最爱提的就是这两个需求，因为单位里总有请假、出差、开会。源码里如果没有这两个功能，早晚要加。转办的实现不复杂，就是改CurrentUserId并追加一条日志；委托则需要一个委托关系表，并在待办查询时把委托人的待办合并到被委托人名下。我在改造老源码时，哪怕原系统没有委托功能，也会预留这个表结构，免得后面上线了再动流程主逻辑。
5. 权限模型逃不开的两张表，还有数据隔离这个更麻烦的问题
公文系统的权限控制和普通网页后台有本质区别。普通后台就是“谁能进哪个菜单”，公文系统要解决的是“谁能看到哪篇公文、能对哪篇公文做什么操作”。这涉及两层权限：功能权限和数据权限。
功能权限用经典的RBAC模型就够——员工表、角色表、菜单表、角色菜单关联表。这一层大多数Asp.net源码都做了，这里不展开。容易翻车的是数据权限。公文系统里，同样是领导，部门领导只能看到本部门的文件，分管领导能看到分管条线的文件，办公室的机要员能看所有文件但不能乱批。如果只是用角色去匹配公文可见范围，很快就会乱套。
我在设计数据权限时喜欢用“数据范围类型”来控制。每个角色配置一个数据范围枚举：1本人、2本部门、3本部门及下级部门、4全部、5按指定部门列表。查询公文时，把这个范围翻译成SQL中的部门过滤条件。比如角色数据范围是“本部门及下级部门”，那就查出本部门所有子部门的Id集合，用IN条件过滤。这套逻辑听着不难，但很多老源码压根没有，全靠给每个用户手动配置能看到哪些文件，上线一个月管理员就疯了。
另外提示一个安全细节。老一些的Asp.net项目默认开了ViewState，页面上还喜欢用Request["id"]取值然后直接拼到SQL里，这套组合很容易被攻击者利用。我在源码评估时会搜页面代码里的SQL拼接位置，Count一下不安全写法出现的频次，如果太普遍，我宁愿自己重新封装数据访问层也不直接在原代码上打补丁。
6. 部署上线最容易翻车的三个环节
6.1 IIS与运行时版本不匹配
很多Asp.net公文系统是在老环境上跑起来的，比如Windows Server 2008加IIS7加.NET Framework 4.0。现在新部署的服务器动不动就是Windows Server 2019或2022，IIS版本到了10以上，如果源码用了比较老的Handler映射方式，或者Web.config里有不兼容的配置节，应用池一启动就可能报500错误。我踩过一次很冤枉的问题：代码本身没问题，就是应用池的“启用32位应用程序”没打开，因为老的数据库驱动装的是32位版本。部署排错时要先看事件查看器，里面会有详细的异常栈，不要一上来就去翻代码。
6.2 数据库初始化脚本的执行顺序
一套靠谱的Asp.net源码一定会带完整的数据库初始化脚本。但脚本质量参差不齐，有的是一整段包含建库建表插数据的SQL，执行完就行；有的是框架自动生成的迁移脚本，需要按先后顺序跑。我遇到过最坑的情况是脚本里有敏感词级联，比如权限表和数据字典表相互引用，直接执行会报外键约束错误。这类问题没有捷径，就是按依赖顺序拆开执行：先建基础表，再建业务表，最后插数据字典。执行前务必备份或建临时库，反复验证两遍再往正式库上动。
6.3 换了一台机器，连接串和文件路径全得改
Web.config里的数据库连接串、附件存储路径、日志目录、甚至发送通知的邮件服务器配置，都需要按新环境改。最容易漏的是附件目录的写入权限。公文系统一定会涉及附件上传，默认上传目录可能配置在某个绝对路径下，新服务器上IIS进程对这个目录没有写权限，用户上传附件时就报“拒绝访问”。这类问题和代码无关，纯属部署配置疏漏，但特别容易让人误以为源码有Bug。我的习惯是部署前做一张环境配置检查表：数据库版本、连接串、附件目录权限、应用池标识、日志目录、SMTP配置逐项打勾，全部通过再开始功能测试。
7. 怎么判断一套Asp.net公文流转源码值不值得二次开发
最后结合这些年的经验，给准备折腾这类源码的朋友一个“五星评估法”。不需要全部满足，但满足的项越多，后续开发越省心。
- 有完整的数据库脚本和基础数据：不是只有业务表，还要有菜单初始化脚本、权限初始数据和管理员账号初始化脚本。我见过不少源码，数据库脚本建出来是一堆空表，菜单数据全靠手工录入，这种项目前期就要消耗大量时间。
- 流程配置和代码分离：节点和流转方向可以放在数据库表里配置，而不是写死在代码的if else里。公文系统最大的特点是流程经常变，机构调整、领导分工变化都会导致流程改变，不能改流程就动代码，否则你永远在改Bug的路上。
- 待办列表实现合理：待办查询应该走数据库索引，而不是全表扫描后内存过滤。同时待办的SQL要能支持分页，不然用户量一多，页面卡死是必然的。
- 工作流日志完整：任何一次操作都有日志记录，包括操作人、时间、动作、意见。这个不仅是为了审计，更是为了用户质询时的追溯依据。
- 权限模型支持数据范围：至少要有“本人、本部门、全部”三种数据范围，不然后面做数据隔离的时候，你会在报表和列表里补大量的SQL条件，改到怀疑人生。
这套评估标准用下来，基本能筛掉一半以上的老Asp.net源码。如果源码不满足也不用太灰心，把它当作参考实现，重点借鉴它的业务表单设计和文号管理思路，然后基于一个更清晰的架构重写工作流核心，其实工作量比在原代码上打补丁还小。
就说这么多吧。我在处理这套源码的时候最大的体会是：公文流转系统的灵魂不在界面，也不在增删改查，而在流程和权限这两个看似不起眼却无处不在的模型设计上。拿到任何一套源码，先把工作流日志表和权限数据范围这两块看明白，后面的改造路径基本就有数了。
本文还有配套的精品资源，点击获取
