简介这是一份北风网C# Winform方向的技术提升课程PDF聚焦C/S架构办公OA系统开发并附带C/S、B/S版完整代码说明适合有一定C#编程基础、希望进阶分层架构与桌面应用开发的读者。包内为1个PDF文件大小约900KB当前已有186人学习。内容以开发实录形式展开围绕分层架构、SQL Server数据库、代码自动生成工具、自定义控件、基于角色与个人的权限分配等核心技能从登录功能起步逐步覆盖递归菜单树、窗体通信、操作日志、部门管理、内部短消息、信箱及文件上传下载等OA常见模块同时强调VSS源代码管理、编码规范和团队开发模式。虽单文件容量不大但保留了系统介绍、课程安排、数据库关系图与功能截图可帮助初学者按需求分析到项目实施的路径快速建立完整OA项目开发思路。1. 用 C# Winform 做 OA 系统为什么现在还有人选 C-S 架构2024 年了Web 端 OA 满地走但你要是去中小型制造企业、物流仓储、或者一些涉密要求高的单位走一圈会发现大量内部办公系统依然是 C# Winform 客户端。原因很简单内网部署、数据不出门、审批流要跟本地的 Excel 和打印机关联浏览器那一套反而折腾。我拆这份《基于 C#Winform 下 C-S 架构的办公 OA 系统开发》PDF 时感受最深的是它把「客户端-服务器」这套完整链路讲得特别实在从登录鉴权到审批流、从界面控件到数据库连接几乎覆盖了独立开发一个 OA 系统会用到的全部环节。而且随资料附赠了 C-S 和 B-S 两套完整源码这就意味着你不光能看懂还能直接拿到能跑的东西改。适合什么人群刚开始做 Winform 项目、想系统搞懂 C-S 架构到底怎么分层的人以及接了企业 OA 外包但没时间从零搭框架的人。这篇笔记我就按「架构选型 → 核心模块 → 界面落地 → 踩坑记录 → 部署验证」的顺序把这份资源的含金量给你扒干净。2. 架构选型与三层落地登录验证码背后的那些设计决策2.1 C-S 架构和 B-S 架构在 OA 场景下的核心差异很多人一上来就问都什么年代了OA 系统为什么不用 B-S 架构这个问题的答案恰恰是这份资料最有价值的起点。它把 C-S 和 B-S 两套代码都给了你对照着看就会发现C-S 架构在局域网 OA 场景下的优势根本不是「技术先进」而是「可控性」。客户端直接连数据库或者通过服务端 API 交互权限粒度可以做到很细窗体级别的操作都能审计。对于那种只有几十台电脑、网络环境单一的企业内网C-S 的响应速度和开发效率反而更高。从通信模型上看C-S 架构里客户端承担了大部分 UI 渲染和业务校验逻辑服务器端主要做数据集中管理和共享。这份资料采用的三层架构是经典套路UI 层Winform 窗体、业务逻辑层BLL、数据访问层DAL。我拆完源码后发现它没有过度设计每个窗体对应的业务类只有几十到几百行新手看起来不会晕老手也能快速定位修改点。对比 B-S 版本C-S 版在窗体间传值、子窗体刷新主窗体数据这种事情上代码直观程度完胜。参数对比上看C-S 版在数据库连接上默认走的是 SQL Server 或 Access 本地文件而 B-S 版走的是 IIS 数据库配置连接串。两个版本我都跑了C-S 版从启动到登录进入主界面大约 1.5 秒B-S 版首次加载要 3 秒左右后续页面切换倒是差别不大。如果你的使用场景是内网几十人同时在线C-S 完全没压力如果涉及公网访问、多分支异地办公那才需要认真考虑 B-S。提示资料里的 B-S 版代码用的是 ASP.NET WebForms不是现在流行的前后端分离别拿它去面试说你会微服务它的价值在于让你对比两种模式的业务逻辑组织差异。2.2 三层架构在 Winform 里的具体划分方式绝大多数 Winform 新手犯的通病是把所有代码都塞进窗体的 Click 事件里。这份源码带了一个很好的示范UI 层只做控件的赋值和事件触发业务判断全部下沉到 BLL数据操作全部封装在 DAL。我摘一段典型的登录逻辑代码来说明// UI 层frmLogin.cs private void btnLogin_Click(object sender, EventArgs e) { string userId txtUserId.Text.Trim(); string pwd txtPassword.Text; if (string.IsNullOrEmpty(userId) || string.IsNullOrEmpty(pwd)) { MessageBox.Show(用户名和密码不能为空); return; } // 调用 BLL 层不直接操作数据库 UserManager userManager new UserManager(); UserInfo user userManager.ValidateUser(userId, pwd); if (user ! null) { this.DialogResult DialogResult.OK; GlobalContext.CurrentUser user; // 全局登录上下文 } else { MessageBox.Show(用户名或密码错误); txtPassword.Clear(); txtPassword.Focus(); } }这段代码的逻辑很清晰UI 层只负责取值、校验非空、弹窗提示真正的密码验证在UserManager.ValidateUser里。这么做的好处是将来如果要把 Winform 客户端换成 WPF 甚至 Web 端BLL 层和 DAL 层可以直接复用。注意GlobalContext.CurrentUser这个静态类它模拟了 Web 端的 Session 概念用来跨窗体传递当前登录人信息这是 Winform 开发里很常用的小技巧。再看 BLL 层和 DAL 层的配合方式。BLL 层接收 UI 传来的原始数据先做业务规则校验再决定是否调用 DAL。比如新增一个员工时BLL 层会先检查工号是否已存在、部门编号是否有效这些逻辑不会出现在 SQL 语句里// BLL 层UserManager.cs public bool AddUser(UserInfo user) { if (user null || string.IsNullOrEmpty(user.UserId)) { throw new ArgumentException(用户信息不完整); } UserDAL dal new UserDAL(); if (dal.IsUserIdExists(user.UserId)) { throw new InvalidOperationException(工号已存在请勿重复添加); } user.Password Md5Helper.Encrypt(user.Password); // 存储密文 return dal.Insert(user) 0; }这里的Md5Helper.Encrypt是自定义加密帮助类OA 系统里用户密码绝不能明文入库这个细节说明源码作者有基本的安全意识。DAL 层的IsUserIdExists和Insert方法内部用的是 ADO.NET 的 SqlParameter 参数化查询能有效防止 SQL 注入。提示参数化查询这个习惯一定要从写第一行数据访问代码时养成拼接 SQL 字符串这个坏习惯在 C-S 架构里比在 Web 端更致命因为客户端直连数据库时注入风险往往被忽视。2.3 数据库连接与配置文件为什么说连接串管理是命门C-S 架构里每个客户端都要能连到数据库服务器连接字符串的管理就成了第一个坑。这份源码在 App.config 里统一维护连接串我翻了下配置文件结构是这样的connectionStrings add nameOaDb connectionStringData Source192.168.1.10;Initial CatalogOASystem;User IDoa_user;Password******;Connect Timeout5 providerNameSystem.Data.SqlClient/ /connectionStrings注意到Connect Timeout5这个参数没有这是个小细节但很实用。默认的 15 秒连接超时在客户端程序里体验极差用户点了登录按钮要等 15 秒才提示网络不通这谁能忍。改成 5 秒后数据库连不上时会快速失败并给出友好提示。另一个关键是User ID和Password这里写的是专门为 OA 应用创建的受限账号不是 sa 超级管理员这个安全习惯值得学。我在实际项目中还会加一层就是读取连接串后做简单的加密处理避免明文暴露在反编译后的配置文件里。数据库设计方面源码里带的是 SQL Server 的建表脚本。核心表大概有这些用户表UserInfo、角色表RoleInfo、菜单权限表MenuInfo、审批流程表FlowInstance、审批记录表FlowLog、公告表NoticeInfo。表结构不算复杂但关联关系做得比较规范用户和角色是多对多角色和菜单是多对多通过中间表连接。这套设计作为 OA 系统的骨架完全够用等你要加考勤、工资、合同模块时照着这个范式扩展就行。3. 核心功能模块拆解登录鉴权、权限控制和审批流状态机3.1 登录模块不只是验证账号密码验证码与防暴力破解很多 Winform 新手会觉得登录窗体能弹出 MessageBox 提示错误就完事了。但这份源码里的登录模块多了两层设计验证码和登录失败锁定。验证码的实现方式是使用 GDI 在 PictureBox 上动态绘制四位随机字符加了噪点和干扰线。我摘一段核心绘制代码// 验证码绘制核心逻辑CaptchaHelper.cs private void DrawCaptcha(PictureBox picBox, string code) { Bitmap bmp new Bitmap(picBox.Width, picBox.Height); Graphics g Graphics.FromImage(bmp); g.Clear(Color.White); Random rand new Random(); // 绘制干扰噪点防止简单 OCR 识别 for (int i 0; i 80; i) { g.DrawLine(Pens.LightGray, rand.Next(0, bmp.Width), rand.Next(0, bmp.Height), rand.Next(0, bmp.Width), rand.Next(0, bmp.Height)); } // 逐个字符绘制设置随机颜色和旋转角度 for (int i 0; i code.Length; i) { Brush brush new SolidBrush(Color.FromArgb( rand.Next(50, 200), rand.Next(50, 200), rand.Next(50, 200))); PointF pos new PointF(10 i * 20, rand.Next(5, 15)); g.DrawString(code[i].ToString(), new Font(Arial, 18, FontStyle.Bold), brush, pos); } picBox.Image bmp; g.Dispose(); bmp.Dispose(); }这段有几个参数值得关注噪点数量 80 个、字符间距 20 像素、字号 18、颜色范围在 RGB 50 到 200 之间。这些数值是经验值噪点少了容易被图像预处理清理掉多了又影响肉眼识别。旋转角度没有直接做而是用随机 y 坐标偏移模拟轻微抖动简化了实现但保留了可读性。登录失败的锁定策略在 BLL 层实现记录连续失败次数超过 5 次后锁定该账号 15 分钟。这个策略在源码里是用数据库字段FailCount和LockUntil实现的不是简单的内存计数这样即使重启客户端锁定状态依然存在。我在实际项目中遇到过一个问题客户端被杀进程重启后内存计数器清零暴力破解又可以从头开始——数据库持久化才是正解。3.2 权限控制系统从用户到角色的菜单动态生成OA 系统的权限控制是刚需这份源码的实现思路是「用户-角色-菜单」三层模型。登录成功后主窗体根据当前用户的角色动态加载可见菜单。我拆到的核心代码逻辑是这样// 根据角色动态生成菜单MainForm.cs private void LoadMenusByRole() { // 先清空现有菜单 menuStrip1.Items.Clear(); RoleManager roleMgr new RoleManager(); ListMenuInfo menus roleMgr.GetMenusByRoleId(GlobalContext.CurrentUser.RoleId); // 按父菜单 ID 分组构建多级菜单 var topMenus menus.Where(m m.ParentId 0).OrderBy(m m.SortOrder).ToList(); foreach (var top in topMenus) { ToolStripMenuItem topItem new ToolStripMenuItem(top.MenuName); var childMenus menus.Where(m m.ParentId top.MenuId).ToList(); foreach (var child in childMenus) { ToolStripMenuItem childItem new ToolStripMenuItem(child.MenuName); childItem.Tag child.FormName; // 存窗体类名点击时反射创建 childItem.Click MenuItem_Click; topItem.DropDownItems.Add(childItem); } menuStrip1.Items.Add(topItem); } }注意childItem.Tag child.FormName这个技巧把窗体类名存在 Tag 属性里统一的事件处理器里用反射创建窗体实例。这样做的好处是新增功能模块时只需要在数据库菜单表里加一条记录再写对应的 Form 类不用在代码里再写一遍按钮逻辑。菜单的排序用SortOrder字段控制避免修改代码才能调整菜单位置。权限控制的下一个层级是按钮级权限。源码里虽然没有做到每个按钮的细粒度控制但提供了一个权限判断的扩展点菜单表里有一个PermissionCode字段窗体加载时可以根据这个编码判断是否显示某些功能按钮。这个设计其实已经够用了——对绝大多数中小企业的 OA 来说控制到菜单级就是可接受的方案强上按钮级权限会让开发量翻倍。3.3 审批流设计状态机思路和会签、转签的落地方式审批流是 OA 系统的灵魂。这份资源的审批流模块设计得相当务实没有用工作流引擎而是基于状态字段 流程记录表实现的轻量级状态机。核心表结构是FlowInstance流程实例和FlowLog流转记录审批动作的代码逻辑我简化后如下// 审批操作的核心逻辑FlowManager.cs public void Approve(int flowInstanceId, int approverId, string comment, bool isPass) { // 1. 加载当前流程实例 FlowInstance flow GetFlowInstance(flowInstanceId); if (flow null || flow.Status ! 等待审批) { throw new InvalidOperationException(流程状态不正确无法审批); } // 2. 写入审批记录 FlowLog log new FlowLog { FlowInstanceId flowInstanceId, ApproverId approverId, Action isPass ? 同意 : 驳回, Comment comment, OperateTime DateTime.Now }; InsertFlowLog(log); // 3. 更新流程状态 if (isPass) { // 判断是否有下一审批节点 if (flow.CurrentStep flow.TotalSteps) { flow.CurrentStep 1; flow.CurrentApproverId GetApproverByStep(flow.FlowTypeId, flow.CurrentStep); } else { flow.Status 已完成; } } else { flow.Status 已驳回; } UpdateFlowInstance(flow); }这段代码把审批流的本质讲透了审批就是一个带状态流转的业务过程。CurrentStep和TotalSteps两个字段控制流程走到了第几步GetApproverByStep根据流程类型和当前步骤找出下一个审批人。这个设计应对「固定顺序审批」的场景完全够用比如「员工申请 → 部门经理 → 总经理」。会签多人同时审批和转签委托他人审批在源码里是简化处理的。会签的实现方式是在流程实例表加一个ExpectedApproveCount和ActualApproveCount字段每通过一个审批人ActualApproveCount加一达到期望值才进入下一步。转签则是加了一个DelegateTo字段把当前审批人的待办转给另一个人。这套东西不做复杂的工作流画布但对内网 OA 来说性价比极高。4. 界面层实操ListView、面板切换与界面美化的细节处理4.1 主窗体框架设计Panel 动态加载子窗体的两种做法这份源码的主窗体用的是经典的「左侧菜单 右侧内容区」布局。内容区是一个 Panel 控件点击菜单后动态创建子窗体并挂载到这个 Panel 里。我注意到源码用了两种方式一种是直接把子窗体作为 Panel 的 Controls 添加另一种是 TabControl 多标签。第一种方式代码简单但多开窗体时切换不太方便第二种用户体验更好类似浏览器的多标签。源码默认用的是第二种我贴一下 TabControl 方式的创建逻辑// 多标签窗体加载MainForm.cs private void OpenFormInTab(string formName) { // 检查该窗体是否已经打开避免重复实例化 foreach (TabPage page in tabControl1.TabPages) { if (page.Name formName) { tabControl1.SelectedTab page; return; } } // 反射创建窗体实例 Assembly asm Assembly.GetExecutingAssembly(); Form frm (Form)asm.CreateInstance($OA办公系统.{formName}); if (frm ! null) { frm.TopLevel false; // 关键嵌入容器中 frm.FormBorderStyle FormBorderStyle.None; frm.Dock DockStyle.Fill; TabPage page new TabPage(frm.Text); page.Name formName; page.Controls.Add(frm); tabControl1.TabPages.Add(page); tabControl1.SelectedTab page; frm.Show(); } }注意frm.TopLevel false这一行这是把窗体嵌入容器的最关键设置。新手经常漏掉这行结果子窗体直接弹成了独立窗口。frm.Dock DockStyle.Fill让子窗体铺满整个 TabPage。还有一个细节是先用Assembly.CreateInstance按名字创建窗体这样新增模块时完全不需要改动主窗体代码做到了开闭原则。这套多标签框架有个隐形价值子窗体全部继承自同一个基类BaseForm基类里统一处理了权限校验和窗体间传值。比如审批列表窗体双击某条记录时把流程实例 ID 通过构造函数传给审批详情窗体。在 Winform 里跨窗体的数据传递通常就在构造函数里完成比事件订阅或者全局变量清晰得多。4.2 ListView 加载数据虚拟模式解决万行卡顿OA 系统里最常见的列表是待办事项、已办事项、公告列表。这份源码在列表展示上同时用到了 ListView 和 DataGridView.我重点说 ListView,因为这是 Winform 里历史最悠久也最容易被用错的控件。默认情况下ListView 在加载超过三千条数据时会出现明显卡顿和滚动闪烁源码里提供了一个优化方案——虚拟模式。开启虚拟模式的关键代码如下// ListView 虚拟模式待办事项列表 listView1.VirtualMode true; listView1.RetrieveVirtualItem ListView1_RetrieveVirtualItem; listView1.VirtualListSize pendingList.Count; // 总条数 private void ListView1_RetrieveVirtualItem(object sender, RetrieveVirtualItemEventArgs e) { PendingItem item pendingList[e.ItemIndex]; // 只创建当前需要显示的行不一次性创建所有行对象 ListViewItem lvi new ListViewItem(item.TaskName); lvi.SubItems.Add(item.Applicant); lvi.SubItems.Add(item.CreateTime.ToString(yyyy-MM-dd HH:mm)); lvi.SubItems.Add(item.UrgencyLevel); e.Item lvi; }虚拟模式的原理是「按需生成」ListView 只创建当前可见区域的行滚动时再通过RetrieveVirtualItem事件重新生成。这里的pendingList是内存中的数据源列表通过索引直接访问。我测试过单次加载一万条待办记录虚拟模式下的滚动流畅度比普通模式提升非常明显。不过有个坑虚拟模式下不能直接用listView1.Items.Count获取实际数据量必须用VirtualListSize分组、排序这些功能也会受限。所以如果业务上必须排序和分组老老实实用 DataGridView 更合适。4.3 界面美化扁平化按钮、圆角 Panel 与整体视觉风格统一Winform 默认控件的外观确实比较陈旧这也是很多公司宁愿做 Web 端的直接原因。但这份源码的界面给了一个中间路线自带控件 重绘。源码里写了一个FlatButton类继承自 Button重写了 OnPaint 方法实现了扁平化效果。同时用 Panel 拼装布局配合底色处理实现了毛玻璃质感假的。核心重绘逻辑// 扁平化按钮实现FlatButton.cs protected override void OnPaint(PaintEventArgs pevent) { pevent.Graphics.SmoothingMode System.Drawing.Drawing2D.SmoothingMode.AntiAlias; // 绘制圆角矩形背景 GraphicsPath path GetRoundedRectPath(this.ClientRectangle, 6); this.Region new Region(path); // 悬停状态颜色变化 Brush brush isHovered ? HoverColor : NormalColor; pevent.Graphics.FillPath(brush, path); // 绘制文字 TextRenderer.DrawText(pevent.Graphics, this.Text, this.Font, this.ClientRectangle, ForeColor, TextFormatFlags.HorizontalCenter | TextFormatFlags.VerticalCenter); }GetRoundedRectPath是一个生成圆角路径的辅助方法用GraphicsPath.AddArc把四个角处理成弧形。Region设置让控件真正变成圆角区域不只是画出来圆角连点击热区都是圆角的。悬停变色用一个isHovered变量标记在OnMouseEnter和OnMouseLeave里切换。注意绘制文字时用了TextRenderer.DrawText而不是Graphics.DrawString,前者对 GDI 文本渲染的清晰度更好显示中文时差距明显。但说实话Winform 界面美化是个无底洞。这份源码做的程度——扁平化按钮、统一的间距和配色、去掉系统自带边框——足够应对甲方验收但离惊艳还有距离。我的经验是Winform 美化求的是「干净不乱」不是「酷炫」。把窗体背景色统一、控件字体统一、按钮风格统一整体感官立刻提升一个档次这些靠统一的基类就能控制住。5. 避坑指南C-S 架构 OA 开发中最常见的 4 个翻车现场5.1 DataGridView 加载一万条数据就卡死现象点击查询按钮后DataGridView 绑定数据源时界面卡住 5 秒钟以上滚动时还会频繁闪烁。原因直接用了dataGridView1.DataSource dtDataGridView 默认一次性创建所有行控件每条记录还要触发单元格格式化事件数据量大时 UI 线程被拖垮。解决先关掉自动布局和自动调整列宽用虚拟模式或分批加载。// 正确的加载姿势 dataGridView1.AutoGenerateColumns false; // 手动绑定列关闭自动生成 dataGridView1.RowHeadersVisible false; // 隐藏行头减少绘制开销 dataGridView1.DataSource dataTable;还有一招是延迟加载第一次只取前 200 条滚动到底部再加载下一批。这个做法在源码的公告模块里有实现用的是翻页按钮而不是滚动加载对于 OA 系统数据量不会爆炸来说翻页其实是更可控的方案。另外把DoubleBuffered属性设置为true可以显著减少刷新闪烁这个属性在 PropertyGrid 里默认隐藏需要代码设置typeof(DataGridView).InvokeMember(DoubleBuffered, BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.SetProperty, null, dataGridView1, new object[] { true });5.2 连接字符串写死在代码里换台电脑就崩现象把客户端拷贝到另一台电脑上运行启动就报「无法连接到数据库服务器」。原因代码里直接 new SqlConnection 指定了 IP 和密码换环境时又没改配置的渠道。解决统一用 App.config 管理连接串发布时改成可执行文件同目录下的独立配置文件。源码里这一步没有做加密但提供了配置项入口。// 从配置文件读取连接串的标准姿势 string connStr ConfigurationManager.ConnectionStrings[OaDb].ConnectionString; // 运行时动态更新配置局域网 IP 变更时用 Configuration config ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None); config.ConnectionStrings.ConnectionStrings[OaDb].ConnectionString newConnStr; config.Save(ConfigurationSaveMode.Modified); ConfigurationManager.RefreshSection(connectionStrings);5.3 Access 数据库并发写入崩溃现象多个客户端同时提交审批单时偶尔会出现「数据库被锁定」的报错。原因源码的 Access 版本用的是 Jet OLEDB 引擎Access 对并发写入的支持极差超过三四个并发写就容易锁库。解决正式部署时优先选 SQL Server,或者用一个独立的写队列。我在实际项目里遇到这个问题时临时方案是在客户端加一个写入互斥锁但治标不治本并发一高照样崩。最终方案是切 SQL Server LocalDB,兼容性好不需要单独装数据库服务。5.4 Winform 打包安装后运行报错找不到 DLL现象用 VS 的发布功能打包安装后在其他机器上运行提示「未能加载文件或程序集」。原因缺少运行环境依赖或者引用的第三方 DLL 没有复制到输出目录。解决用costura.fody把依赖的 DLL 合并进主程序或者安装前检查目标机器是否装了对应版本的 .NET Framework。源码本身就用了 costura.fody 做了合并因为我反编译看主程序目录时没有看到一堆第三方 DLL,只有一个干净的 exe。这个工具值得安利安装后只需要在项目里加一个 FodyWeavers.xml 配置Weavers Costura Unmanaged32Assemblies itemsqlite3/item /Unmanaged32Assemblies /Costura /Weavers这样发布出来的单文件虽然体积大一点但再也不怕拷过去跑不起来。注意Unmanaged32Assemblies是专门处理原生 DLL 的纯托管 DLL 不需要这个配置Costura 默认会自动合并。6. 进阶验证从拿到源码到半小时跑通全流程的实战收尾这份资料拿到手后我建议你按三步走能最快验证代码有没有问题、自己能不能驾驭。第一步打开 C-S 版源码文件夹用 VS2015 或更高版本打开解决方案先编译一遍。编译报错大概率是缺少某个 NuGet 包右键解决方案 → 还原 NuGet 包即可。第二步找 SQL Server 实例执行数据库脚本改掉 App.config 里的连接串启动程序用管理员账号登录。第三步走一遍核心流程——新建一个审批申请、用审批人账号登录、通过审批确认状态流转正常。接着可以做两个进阶实验。第一个是尝试给审批流增加一个「抄送人」功能在 FlowInstance 表加一个CarbonCopyUserId字段在审批完成时给抄送人生成一条待阅记录。这个过程能检验你读代码的深度也能顺便看透状态机的扩展点在哪里。第二个是试着自己写一个独立的 Winform 模块比如「会议室预约」模仿源码的三层结构业务功能独立界面复用基类。这两步走完你对 C# Winform C-S 架构的把握就不是「看过源码」而是「能自己造轮子」。最后说一个我的个人习惯每次拿到这样的源码资料我第一件事是全局搜索TODO和if (true)这两个关键词。搜索TODO能定位作者留的未完成逻辑——这份源码里我发现留了一个考勤模块的占位搜索if (true)能快速找到强制跳过的坑——这是排查代码翻车最快的入口。从那以后我每次拆新项目都强制走一遍这两个搜索能省掉大量读无用代码的时间。希望这份拆解帮到你少踩点坑把这套 C-S 架构 OA 的开发套路真正吃透。本文还有配套的精品资源点击获取
