1. 项目概述先说结论用 ASP.NET 做客户关系管理系统CRM到今天依然是很多中小型企业内部数字化改造的首选方案。原因很直接——生态成熟、招人容易、部署门槛低尤其对于已经站在微软技术栈上的团队几乎是零成本起步。这个项目表面上是一个“客户关系管理系统”但拆开来看它其实覆盖了三层核心需求第一层是客户数据的集中管理把散落在 Excel、微信聊天记录、名片夹里的客户信息统一收口第二层是销售过程的漏斗化管理从线索到成交的每个阶段都要有迹可循第三层是数据驱动决策通过报表和统计让管理者能看清团队的真实产出。我基于 ASP.NET 搭建这套系统时没有追求花哨的前端框架也没有上来就搞微服务核心思路就是“实用优先能跑起来再说跑稳了再优化”。对于大多数业务场景一个结构清晰的分层架构加上一套合适的权限模型远比技术选型上的炫技重要得多。这篇文章适合谁看如果你是刚接触 .NET 开发的初级工程师想了解一个完整的业务系统是如何从零搭建的或者你是团队的技术负责人正在评估自研 CRM 还是买现成产品又或者你只是单纯想看看 ASP.NET 在实际项目里怎么落地——这篇文章都能给你提供一个完整的参考样本。2. 整体架构设计思路2.1 为什么选 ASP.NET 而不是其他技术栈我在决定技术方案时其实纠结过一阵子。当时摆在面前的选项有 Java Spring Boot、Python Django、还有 Node.js。最后选了 ASP.NET核心原因有三个。第一是团队技能匹配。团队成员对 C# 和 Visual Studio 的熟悉程度远高于其他语言省去了从零学习的时间成本。这里有一个很容易被低估的点技术选型不是选“最好的”而是选“团队最能驾驭的”。再好的框架如果团队不熟上线后出了生产事故都没人敢改。第二是 Windows 服务器环境下的一体化体验。客户那边的基础设施是 Windows Server SQL ServerASP.NET 在这个环境下可以说是“主场作战”。第三是生态组件齐全。从身份认证ASP.NET Identity、ORMEntity Framework到报表组件、导出 Excel 的类库微软生态里都有现成的方案可用不用到处找第三方库拼凑。2.2 分层架构经典的三层模式整个系统我采用了比较经典的三层架构没有引入过于复杂的 DDD 或 CQRS 模式。原因很简单CRM 的核心业务逻辑并不算特别复杂过度设计只会拖慢开发进度。表现层ASP.NET MVC Controllers Views ↓ 业务层Service Layer处理业务规则 ↓ 数据访问层EF Core Repository Pattern ↓ 数据库SQL Server 2019这里我说一下为什么没用 WebForms 而是选了 MVC。虽然 WebForms 在某些场景下开发效率确实高比如快速做后台管理界面但它的 ViewState 机制和事件驱动模型在多人协作和前后端分离的大趋势下显得越来越笨重。MVC 模式的优势在于关注点分离——路由控制、模型绑定、视图渲染各自独立单元测试也更好写。后来我又重构过一版把表现层拆成了 ASP.NET Core Web API 独立的前端项目Vue 3但其实底层的业务层和数据层没怎么动。这也验证了三层架构的一个好处只要边界划得清楚以后换前端也好、换数据库也好影响面都是可控的。2.3 数据库设计的关键决策CRM 系统的数据库设计是整个项目的基石表结构设计得好不好直接决定后续开发的顺不顺。我总结下来有几个关键决策值得记录。第一客户表Customer和联系人表Contact必须分离。很多初学 CRM 开发的人容易把这两者混在一起觉得“联系人不就是客户的联系方式吗”实际上一个客户公司往往有多个联系人比如采购经理、技术负责人、财务总监他们各自分管不同环节混在一张表里会导致数据冗余和更新异常。第二跟进记录FollowUp表必须有独立的业务状态字段。客户的跟进过程不是简单的“添加备注”而是一条有时间线、有状态、有归属人的完整记录链。我设计的 FollowUp 表包含了跟进方式电话/拜访/微信/邮件、沟通摘要、下次跟进时间、当前销售阶段等字段这让后续的销售漏斗分析有了数据基础。第三所有业务表统一包含 CreateTime、UpdateTime、CreateBy、UpdateBy 四个审计字段。这是很多开发人员容易忽略的细节等到业务方说“帮我查一下这个客户是谁在什么时候录入的”的时候没有这些字段就只能干瞪眼。3. 核心技术点拆解与实现3.1 基于 ASP.NET Identity 的权限管理CRM 系统的权限管理比一般系统要复杂一些因为它的用户角色天然是分层的——普通销售只能看自己的客户销售主管能看团队所有客户的跟进情况管理员能配置系统参数和账号。我用的是 ASP.NET Identity 框架配合自定义的角色授权策略。具体做法是在 Startup 里配置身份验证服务然后为不同的 Controller Action 打上特性标签。// 配置身份验证和授权 services.AddIdentityApplicationUser, ApplicationRole() .AddEntityFrameworkStoresApplicationDbContext() .AddDefaultTokenProviders(); services.ConfigureIdentityOptions(options { // 密码策略至少8位含字母和数字 options.Password.RequireDigit true; options.Password.RequiredLength 8; options.Password.RequireNonAlphanumeric false; });在 Controller 层的使用方式也很直接[Authorize(Roles Admin,Manager)] public IActionResult AllCustomers() { // 只有管理员和主管能查看全量客户列表 return View(_customerService.GetAllCustomers()); } [Authorize] public IActionResult MyCustomers() { // 普通登录用户只能看到自己的客户 var userId User.Identity.Name; return View(_customerService.GetCustomersByOwner(userId)); }这里有个经验教训权限控制不能只做在 UI 层比如隐藏按钮、隐藏菜单服务层必须有对应的数据过滤逻辑。因为 UI 层的控制只是用户体验层面的如果 API 被直接调用数据过滤就形同虚设了。3.2 客户去重与查重策略做 CRM 的人都会遇到一个真实痛点客户数据重复。同一个客户可能被不同销售分别录入甚至同一个人也能录好几遍。数据一重复统计报表瞬间失真管理者看到的市场规模可能比实际翻了一倍。我在系统里实现了三重查重机制第一重创建时实时查重。当用户输入客户名称并移开焦点时前端异步请求后端接口模糊匹配已有客户名称返回相似客户列表供用户确认。第二重防止提交重复数据的约束校验。通过数据库层面的唯一索引客户名称客户所在城市从最底层杜绝完全重复的数据。CREATE UNIQUE INDEX IX_Customer_DuplicateCheck ON Customers (CustomerName, City);第三重定期的后台批量合并工具。已经存在的重复数据通过管理员的“查重合并”功能选择保留的主记录将被合并记录下的联系人、跟进记录等数据迁移到主记录下并做逻辑删除标记。这三重机制下来系统运行半年后的数据重复率从最初的 12% 降到了 1% 以内效果相当明显。3.3 销售漏斗与阶段转化统计CRM 系统如果只做到“记录客户信息跟进记录”那充其量只是一个电子通讯录。真正有价值的模块是销售漏斗——把客户从初步接触到最终成单的全过程阶段化并用数据展示转化效率。我的销售阶段设计是这样的阶段说明预计转化周期线索刚获取到基础信息尚未有效沟通无初步沟通已电话/微信联系上确认有需求意向1-2周方案报价已发送方案或报价进入商务谈判2-4周合同审批双方达成初步一致走合同流程1周成单合同签署进入交付阶段-漏斗统计的实现核心是那张历史状态变更表CustomerStageHistory每当客户的销售阶段发生变化时系统自动追加一条记录包含变更前后的阶段、变更人、变更时间和备注。这样管理者不仅能看到当前有多少客户处在某个阶段还能回溯任意客户在销售周期中的完整路径。报表展示上我用一个简单的柱状图展示各阶段客户数量和金额。这里要吐槽一下很多人一上来就考虑引入 ECharts、Highcharts 这类前端图表库但如果你只是内部管理使用先用原生 CSSHTML 画简单图表是性价比最高的方案——加载快、零依赖、调试方便。3.4 数据字典驱动的可配置化设计CRM 系统里有很多字段是“写死的”比如客户来源展会、官网、朋友介绍、广告投放和客户行业制造业、服务业、IT。一开始我把这些值直接写成枚举或下拉列表在代码里结果业务方每隔一两个月就会提出“再加一个来源类型”。后来我引入了数据字典表SysDictionary把这些易变的枚举值全部迁移到配置表里通过缓存机制加载到应用程序中管理员可以在后台自行维护选项值不需要改代码、重新部署。public class SysDictionary { public int Id { get; set; } public string DictType { get; set; } // 字典类型如 CustomerSource public string DictValue { get; set; } // 选项值如 行业展会 public int SortOrder { get; set; } // 排序 public bool IsEnabled { get; set; } // 是否启用 }这个改动看起来不大但项目的维护成本从此降低了一大截。业务方的满意度也明显上升——因为他们发现不用再通过“提需求-排期-发版”这套流程才能加一个选项了。4. 168个亿级痛点的排查与解决实录4.1 客户列表加载慢N1 查询问题系统上线两周后我接到反馈说客户列表页越用越卡。刚开始没太在意觉得是网络问题或者服务器性能不够。直到自己亲手试了一下发现打开 1000 条客户记录要等足足 6 秒这明显是有问题了。一查代码问题出在 Entity Framework 的懒加载Lazy Loading上。列表页要显示每个客户的最新跟进记录代码里写的是这样的var customers _context.Customers.ToList(); foreach (var item in customers) { var latestFollowUp item.FollowUps.OrderByDescending(f f.FollowTime).FirstOrDefault(); // 每次都触发一条 SQL 查询 }这段代码表面上是查了一次客户表但实际上每遍历一个客户就会额外查询一次 FollowUps 表1000 个客户就是 1001 次数据库往返性能能不差吗解决方案有两个方案一是使用贪婪加载Eager Loading但没法直接加载每条客户记录的最新一条不适合这种情况。方案二是改用显式一次性查询把最新跟进记录用 SQL 按子查询方式查出来当时用的是 EF Core 的 GroupBy 来模拟窗口函数的效果var latestFollowUps _context.FollowUps .GroupBy(f f.CustomerId) .Select(g new { CustomerId g.Key, LatestFollowUp g.OrderByDescending(f f.FollowTime).FirstOrDefault() }) .ToList();改完之后列表页从 6 秒直接降到 300 毫秒——没有加任何硬件资源纯粹是查询逻辑优化效果立竿见影。这也是我反复强调“ORM 好用但也要懂底层 SQL 逻辑”的原因。4.2 死锁问题并发更新同一客户记录系统上线几个月后开始有销售反馈——平时操作好好的偶尔保存跟进记录时会报“事务死锁请重试”。这个问题的典型场景是销售 A 和销售 B 几乎同时给同一个客户添加跟进记录两条 update 语句同时对同一行数据加锁导致死锁。排查死锁的标准路径是这几步第一开启 SQL Server 的阻塞监控查看死锁日志DBCC TRACEON (1222, -1) -- 将死锁信息输出到错误日志第二查看错误日志里 deadlock-list 节点分析导致死锁的两条 SQL 语句和加锁资源。第三针对问题重构代码逻辑。我的解决方式是把“查询客户添加跟进记录”这两个操作合并到一个短事务中并且调整更新顺序让所有对 Customer 表的更新都按同一顺序获取锁using (var transaction _context.Database.BeginTransaction()) { // 先锁定客户行此时以客户的 Id 为锁粒度 var customer await _context.Customers .Where(c c.Id customerId) .FirstOrDefaultAsync(); // 插入跟进记录 _context.FollowUps.Add(new FollowUp { ... }); await _context.SaveChangesAsync(); // 更新客户的最近跟进时间和阶段 customer.LastFollowTime DateTime.Now; customer.Stage currentStage; await _context.SaveChangesAsync(); transaction.Commit(); }另外我还在数据库层面加了一个优化把FollowUps.FollowTime字段的索引改成包含客户 Id 的复合索引减少锁定的范围。这一套组合拳下来死锁在之后半年里再没出现过。4.3 导出 Excel 中文乱码问题CRM 系统肯定逃不过导出 Excel 的需求。销售要导出自己名下的客户清单管理层要导出漏斗分析报表。这里有一个很经典的坑——用老式方法导出 CSV 或者简单拼接 HTML 后改后缀名的方式生成的 Excel 文件在中文 Windows 环境下容易乱码。正确的做法是引入成熟的 Excel 库比如 EPPlus 或者 NPOI。但即便用了库也会遇到另一个坑EPPlus 在非商业环境下免费但公司使用是需要购买商业许可的从 EPPlus 4.5 开始。// 基于 EPPlus 的导出实现需要获取商业授权 using OfficeOpenXml; public byte[] ExportCustomersToExcel(ListCustomerExportDto customers) { using (var package new ExcelPackage()) { var worksheet package.Workbook.Worksheets.Add(客户清单); // 设置表头 worksheet.Cells[1, 1].Value 客户名称; worksheet.Cells[1, 2].Value 所在城市; worksheet.Cells[1, 3].Value 联系人; // ... 填充数据 return package.GetAsByteArray(); } }如果项目预算有限NPOI 是更安全的选择——完全开源免费而且功能覆盖了绝大多数导出需求。我后来为了规避授权风险把项目里的导出组件全部替换到了 NPOI。如果你正在评估新项目直接选 NPOI 可以省去后续的合规隐患。4.4 .NET Framework 3.5 环境问题这个项目在部署过程中还踩过环境相关的坑。客户的服务器是 Windows Server 2016上面默认安装了 .NET Framework 4.x 运行时但旧版业务系统依赖 3.5。我在部署新系统时发现框架冲突导致进程崩溃排查后发现是两个框架版本并行时的程序集加载问题。这里有一个通用经验.NET Framework 3.5 和 4.x 是可以在同一台机器上共存的它们是互相独立的运行时。但 ASP.NET 应用程序池需要显式指定使用哪个版本配置错了就会报Could not load file or assembly之类的异常。如果你遇到的是服务器上安装 .NET Framework 3.5 时报错代码 0x80072f8f网络连接类错误这个通常是因为系统更新服务连不上微软服务器。在用 Windows Server 的“添加角色和功能”安装 .NET Framework 3.5 时可以指定备用源路径指向本地 Windows 镜像文件中的\sources\sxs目录绕开在线下载这个环节。# 使用 Windows Server 2016 镜像安装 .NET Framework 3.5 DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:D:\sources\sxs这类基础环境问题看着和业务代码无关但如果不处理好整个部署流程都会卡住。我的建议是在项目的部署文档里显式记录每个服务器角色的运行时版本要求省得每次换服务器、加环境都要从头踩一遍坑。4.5 GridView 的 jQuery 增强如果你还在用 ASP.NET WebForms 开发内部系统那你一定绕不开 GridView 控件。它虽然有强大的服务端事件机制但前端交互能力很弱——不支持排序动画、不支持前端分页、不支持行内编辑。我当时遇到的需求是客户列表要实现前端侧的无刷新排序而且要带下拉筛选效果。解决方案是引入 jQuery 插件 DataTables配合 GridView 的渲染结果做增强处理。$(document).ready(function () { $(#customerGridView).DataTable({ pageLength: 50, order: [[0, asc]], language: { search: 搜索客户:, lengthMenu: 每页显示 _MENU_ 条, info: 共 _TOTAL_ 条记录当前第 _PAGE_ 页 }, columnDefs: [ { orderable: false, targets: [5, 6] } // 操作列不可排序 ] }); });这里有一个特别注意的地方GridView 渲染出来的表格里操作列编辑、删除按钮的索引可能不固定如果增加隐藏列列索引会变化必须在上面代码里准确指定。一次性配置好之后用户体验提升非常明显——客户列表的翻页、搜索、排序都变成了毫秒级的响应。5. 常用功能模块的实现细节5.1 全局搜索业务方提了一个很朴素的需求“我想快速找到某个客户能不能直接一个搜索框搞定”听起来简单但实现起来要考虑的问题并不少搜索范围是客户名称还是包含联系人姓名搜索条件是精确匹配还是模糊匹配搜索结果按什么排序我最终实现的全局搜索是输入关键词同时匹配客户名称、联系人姓名、联系电话三个字段按客户名称的拼音首字母排序结果中高亮显示匹配的关键词。这个功能用好了销售每天可以省下很多翻列表找客户的时间。5.2 跟进日历视图另一个被高频使用的功能是跟进日历。销售日常工作的核心是“今天该联系谁”也就是系统里设置了下次跟进时间的客户。我实现了一个月历视图按日期展示所有到了跟进节点的客户点击日期能看到当天待跟进的客户列表勾选完成之后自动移动到下一天或下周。这个功能的业务价值在于它把 CRM 从“记录系统”变成了“工作驱动系统”。销售每天打开系统第一眼看到的是今天该干什么而不是一堆死数据。5.3 数据看板管理层最关心的不是某个客户跟得怎么样而是整个团队的业绩健康度。数据看板我做了三个维度本周新增客户数、本周成单金额、当前各阶段漏斗分布。展示在系统登录后的首页让管理者一打开系统就能掌握全局状态。这里要提到一个从实际运营中得来的经验看板上的指标不要超过五个。五项以内的指标管理层能消化吸收超过五项就容易变成“数字摆设”——看起来丰富实际没有人真的会逐个关注每一项。6. 从项目中学到的经验与建议6.1 先理解业务再做技术这个项目给我最大的一个教训是技术人做业务系统最大的风险往往不是技术方案选错而是根本不理解业务方真正需要什么。我第一版 CRM 系统在功能上做得特别“全”客户管理、订单管理、合同管理、售后管理全塞进去了结果上线后数据录入率不到 30%。后来跟销售一线的人深聊才发现他们最痛的点不在于功能少而在于“每天要花大量时间做重复录入”。所以第二版我重点做了几个能减少重复操作的功能客户快速录入、最近联系人自动带出等数据录入率才渐渐到了 80% 以上。所以我的建议是动手写代码之前至少要花一个礼拜贴身观察目标用户的工作流。这看起来效率很低但比起写出一个没人用的系统来这点时间太值了。6.2 版本迭代的节奏控制客户的反馈节奏往往是“刚上线要求稳定稳定之后要求新功能”。面对业务方提出的大量改动需求我的经验是分级处理——零散小改动改字段、调样式直接在当前迭代做跨模块的新需求报表重构、新增流程排进下个迭代战略性需求移动端、数据对接另立项目做调研和规划。有些开发人员习惯把需求一口气全做完再上线这在 CRM 这类业务系统里是大忌。因为 CRM 的很多需求是模糊的不上线跑两周你根本不知道这个功能到底合不合理。快速小步迭代、让用户尽早用起来才是更高效的产品推进方式。6.3 关于 .NET 技术栈的一点看法写完这个项目我对 .NET 技术栈有了更深的体会。ASP.NET 在开发企业级业务系统时依然是非常能打的选择尤其是后端管理类系统——类库丰富、稳定成熟、部署简单团队上手速度也快。虽然国内互联网圈子现在讨论更多的是 Go 和 Java但广大传统企业和政企事业单位的存量系统里.NET 的身影依旧非常多这个生态不会很快消失。如果你还有余力我建议往 ASP.NET Core 方向深入学习特别是它的依赖注入系统、中间件管道模型以及和前端工程化配合的能力。这是一条更长远的路线技术价值也会更高。7. 写在最后的实操建议如果让我给后来者一个建议那就是做 CRM 系统一定要先想清楚“要给谁用、解决什么问题”再做“怎么用更合适的技术实现它”。技术只是手段业务价值才是系统的存续命脉。最后分享一个小技巧在系统里埋一个轻量级的埋点统计比如记录每个登录用户每天在系统里做了哪些操作、在最常用的几个功能上停留了多久。这个数据在系统上线半年后会给你非常宝贵的改进方向——你会发现有些你以为没人用的功能其实被高频使用而有些精心设计的功能却成了摆设。数据不会说谎用它来引导产品走向往往比拍脑袋决策靠谱得多。
ASP.NET实战：从零搭建可落地的CRM客户关系管理系统
1. 项目概述先说结论用 ASP.NET 做客户关系管理系统CRM到今天依然是很多中小型企业内部数字化改造的首选方案。原因很直接——生态成熟、招人容易、部署门槛低尤其对于已经站在微软技术栈上的团队几乎是零成本起步。这个项目表面上是一个“客户关系管理系统”但拆开来看它其实覆盖了三层核心需求第一层是客户数据的集中管理把散落在 Excel、微信聊天记录、名片夹里的客户信息统一收口第二层是销售过程的漏斗化管理从线索到成交的每个阶段都要有迹可循第三层是数据驱动决策通过报表和统计让管理者能看清团队的真实产出。我基于 ASP.NET 搭建这套系统时没有追求花哨的前端框架也没有上来就搞微服务核心思路就是“实用优先能跑起来再说跑稳了再优化”。对于大多数业务场景一个结构清晰的分层架构加上一套合适的权限模型远比技术选型上的炫技重要得多。这篇文章适合谁看如果你是刚接触 .NET 开发的初级工程师想了解一个完整的业务系统是如何从零搭建的或者你是团队的技术负责人正在评估自研 CRM 还是买现成产品又或者你只是单纯想看看 ASP.NET 在实际项目里怎么落地——这篇文章都能给你提供一个完整的参考样本。2. 整体架构设计思路2.1 为什么选 ASP.NET 而不是其他技术栈我在决定技术方案时其实纠结过一阵子。当时摆在面前的选项有 Java Spring Boot、Python Django、还有 Node.js。最后选了 ASP.NET核心原因有三个。第一是团队技能匹配。团队成员对 C# 和 Visual Studio 的熟悉程度远高于其他语言省去了从零学习的时间成本。这里有一个很容易被低估的点技术选型不是选“最好的”而是选“团队最能驾驭的”。再好的框架如果团队不熟上线后出了生产事故都没人敢改。第二是 Windows 服务器环境下的一体化体验。客户那边的基础设施是 Windows Server SQL ServerASP.NET 在这个环境下可以说是“主场作战”。第三是生态组件齐全。从身份认证ASP.NET Identity、ORMEntity Framework到报表组件、导出 Excel 的类库微软生态里都有现成的方案可用不用到处找第三方库拼凑。2.2 分层架构经典的三层模式整个系统我采用了比较经典的三层架构没有引入过于复杂的 DDD 或 CQRS 模式。原因很简单CRM 的核心业务逻辑并不算特别复杂过度设计只会拖慢开发进度。表现层ASP.NET MVC Controllers Views ↓ 业务层Service Layer处理业务规则 ↓ 数据访问层EF Core Repository Pattern ↓ 数据库SQL Server 2019这里我说一下为什么没用 WebForms 而是选了 MVC。虽然 WebForms 在某些场景下开发效率确实高比如快速做后台管理界面但它的 ViewState 机制和事件驱动模型在多人协作和前后端分离的大趋势下显得越来越笨重。MVC 模式的优势在于关注点分离——路由控制、模型绑定、视图渲染各自独立单元测试也更好写。后来我又重构过一版把表现层拆成了 ASP.NET Core Web API 独立的前端项目Vue 3但其实底层的业务层和数据层没怎么动。这也验证了三层架构的一个好处只要边界划得清楚以后换前端也好、换数据库也好影响面都是可控的。2.3 数据库设计的关键决策CRM 系统的数据库设计是整个项目的基石表结构设计得好不好直接决定后续开发的顺不顺。我总结下来有几个关键决策值得记录。第一客户表Customer和联系人表Contact必须分离。很多初学 CRM 开发的人容易把这两者混在一起觉得“联系人不就是客户的联系方式吗”实际上一个客户公司往往有多个联系人比如采购经理、技术负责人、财务总监他们各自分管不同环节混在一张表里会导致数据冗余和更新异常。第二跟进记录FollowUp表必须有独立的业务状态字段。客户的跟进过程不是简单的“添加备注”而是一条有时间线、有状态、有归属人的完整记录链。我设计的 FollowUp 表包含了跟进方式电话/拜访/微信/邮件、沟通摘要、下次跟进时间、当前销售阶段等字段这让后续的销售漏斗分析有了数据基础。第三所有业务表统一包含 CreateTime、UpdateTime、CreateBy、UpdateBy 四个审计字段。这是很多开发人员容易忽略的细节等到业务方说“帮我查一下这个客户是谁在什么时候录入的”的时候没有这些字段就只能干瞪眼。3. 核心技术点拆解与实现3.1 基于 ASP.NET Identity 的权限管理CRM 系统的权限管理比一般系统要复杂一些因为它的用户角色天然是分层的——普通销售只能看自己的客户销售主管能看团队所有客户的跟进情况管理员能配置系统参数和账号。我用的是 ASP.NET Identity 框架配合自定义的角色授权策略。具体做法是在 Startup 里配置身份验证服务然后为不同的 Controller Action 打上特性标签。// 配置身份验证和授权 services.AddIdentityApplicationUser, ApplicationRole() .AddEntityFrameworkStoresApplicationDbContext() .AddDefaultTokenProviders(); services.ConfigureIdentityOptions(options { // 密码策略至少8位含字母和数字 options.Password.RequireDigit true; options.Password.RequiredLength 8; options.Password.RequireNonAlphanumeric false; });在 Controller 层的使用方式也很直接[Authorize(Roles Admin,Manager)] public IActionResult AllCustomers() { // 只有管理员和主管能查看全量客户列表 return View(_customerService.GetAllCustomers()); } [Authorize] public IActionResult MyCustomers() { // 普通登录用户只能看到自己的客户 var userId User.Identity.Name; return View(_customerService.GetCustomersByOwner(userId)); }这里有个经验教训权限控制不能只做在 UI 层比如隐藏按钮、隐藏菜单服务层必须有对应的数据过滤逻辑。因为 UI 层的控制只是用户体验层面的如果 API 被直接调用数据过滤就形同虚设了。3.2 客户去重与查重策略做 CRM 的人都会遇到一个真实痛点客户数据重复。同一个客户可能被不同销售分别录入甚至同一个人也能录好几遍。数据一重复统计报表瞬间失真管理者看到的市场规模可能比实际翻了一倍。我在系统里实现了三重查重机制第一重创建时实时查重。当用户输入客户名称并移开焦点时前端异步请求后端接口模糊匹配已有客户名称返回相似客户列表供用户确认。第二重防止提交重复数据的约束校验。通过数据库层面的唯一索引客户名称客户所在城市从最底层杜绝完全重复的数据。CREATE UNIQUE INDEX IX_Customer_DuplicateCheck ON Customers (CustomerName, City);第三重定期的后台批量合并工具。已经存在的重复数据通过管理员的“查重合并”功能选择保留的主记录将被合并记录下的联系人、跟进记录等数据迁移到主记录下并做逻辑删除标记。这三重机制下来系统运行半年后的数据重复率从最初的 12% 降到了 1% 以内效果相当明显。3.3 销售漏斗与阶段转化统计CRM 系统如果只做到“记录客户信息跟进记录”那充其量只是一个电子通讯录。真正有价值的模块是销售漏斗——把客户从初步接触到最终成单的全过程阶段化并用数据展示转化效率。我的销售阶段设计是这样的阶段说明预计转化周期线索刚获取到基础信息尚未有效沟通无初步沟通已电话/微信联系上确认有需求意向1-2周方案报价已发送方案或报价进入商务谈判2-4周合同审批双方达成初步一致走合同流程1周成单合同签署进入交付阶段-漏斗统计的实现核心是那张历史状态变更表CustomerStageHistory每当客户的销售阶段发生变化时系统自动追加一条记录包含变更前后的阶段、变更人、变更时间和备注。这样管理者不仅能看到当前有多少客户处在某个阶段还能回溯任意客户在销售周期中的完整路径。报表展示上我用一个简单的柱状图展示各阶段客户数量和金额。这里要吐槽一下很多人一上来就考虑引入 ECharts、Highcharts 这类前端图表库但如果你只是内部管理使用先用原生 CSSHTML 画简单图表是性价比最高的方案——加载快、零依赖、调试方便。3.4 数据字典驱动的可配置化设计CRM 系统里有很多字段是“写死的”比如客户来源展会、官网、朋友介绍、广告投放和客户行业制造业、服务业、IT。一开始我把这些值直接写成枚举或下拉列表在代码里结果业务方每隔一两个月就会提出“再加一个来源类型”。后来我引入了数据字典表SysDictionary把这些易变的枚举值全部迁移到配置表里通过缓存机制加载到应用程序中管理员可以在后台自行维护选项值不需要改代码、重新部署。public class SysDictionary { public int Id { get; set; } public string DictType { get; set; } // 字典类型如 CustomerSource public string DictValue { get; set; } // 选项值如 行业展会 public int SortOrder { get; set; } // 排序 public bool IsEnabled { get; set; } // 是否启用 }这个改动看起来不大但项目的维护成本从此降低了一大截。业务方的满意度也明显上升——因为他们发现不用再通过“提需求-排期-发版”这套流程才能加一个选项了。4. 168个亿级痛点的排查与解决实录4.1 客户列表加载慢N1 查询问题系统上线两周后我接到反馈说客户列表页越用越卡。刚开始没太在意觉得是网络问题或者服务器性能不够。直到自己亲手试了一下发现打开 1000 条客户记录要等足足 6 秒这明显是有问题了。一查代码问题出在 Entity Framework 的懒加载Lazy Loading上。列表页要显示每个客户的最新跟进记录代码里写的是这样的var customers _context.Customers.ToList(); foreach (var item in customers) { var latestFollowUp item.FollowUps.OrderByDescending(f f.FollowTime).FirstOrDefault(); // 每次都触发一条 SQL 查询 }这段代码表面上是查了一次客户表但实际上每遍历一个客户就会额外查询一次 FollowUps 表1000 个客户就是 1001 次数据库往返性能能不差吗解决方案有两个方案一是使用贪婪加载Eager Loading但没法直接加载每条客户记录的最新一条不适合这种情况。方案二是改用显式一次性查询把最新跟进记录用 SQL 按子查询方式查出来当时用的是 EF Core 的 GroupBy 来模拟窗口函数的效果var latestFollowUps _context.FollowUps .GroupBy(f f.CustomerId) .Select(g new { CustomerId g.Key, LatestFollowUp g.OrderByDescending(f f.FollowTime).FirstOrDefault() }) .ToList();改完之后列表页从 6 秒直接降到 300 毫秒——没有加任何硬件资源纯粹是查询逻辑优化效果立竿见影。这也是我反复强调“ORM 好用但也要懂底层 SQL 逻辑”的原因。4.2 死锁问题并发更新同一客户记录系统上线几个月后开始有销售反馈——平时操作好好的偶尔保存跟进记录时会报“事务死锁请重试”。这个问题的典型场景是销售 A 和销售 B 几乎同时给同一个客户添加跟进记录两条 update 语句同时对同一行数据加锁导致死锁。排查死锁的标准路径是这几步第一开启 SQL Server 的阻塞监控查看死锁日志DBCC TRACEON (1222, -1) -- 将死锁信息输出到错误日志第二查看错误日志里 deadlock-list 节点分析导致死锁的两条 SQL 语句和加锁资源。第三针对问题重构代码逻辑。我的解决方式是把“查询客户添加跟进记录”这两个操作合并到一个短事务中并且调整更新顺序让所有对 Customer 表的更新都按同一顺序获取锁using (var transaction _context.Database.BeginTransaction()) { // 先锁定客户行此时以客户的 Id 为锁粒度 var customer await _context.Customers .Where(c c.Id customerId) .FirstOrDefaultAsync(); // 插入跟进记录 _context.FollowUps.Add(new FollowUp { ... }); await _context.SaveChangesAsync(); // 更新客户的最近跟进时间和阶段 customer.LastFollowTime DateTime.Now; customer.Stage currentStage; await _context.SaveChangesAsync(); transaction.Commit(); }另外我还在数据库层面加了一个优化把FollowUps.FollowTime字段的索引改成包含客户 Id 的复合索引减少锁定的范围。这一套组合拳下来死锁在之后半年里再没出现过。4.3 导出 Excel 中文乱码问题CRM 系统肯定逃不过导出 Excel 的需求。销售要导出自己名下的客户清单管理层要导出漏斗分析报表。这里有一个很经典的坑——用老式方法导出 CSV 或者简单拼接 HTML 后改后缀名的方式生成的 Excel 文件在中文 Windows 环境下容易乱码。正确的做法是引入成熟的 Excel 库比如 EPPlus 或者 NPOI。但即便用了库也会遇到另一个坑EPPlus 在非商业环境下免费但公司使用是需要购买商业许可的从 EPPlus 4.5 开始。// 基于 EPPlus 的导出实现需要获取商业授权 using OfficeOpenXml; public byte[] ExportCustomersToExcel(ListCustomerExportDto customers) { using (var package new ExcelPackage()) { var worksheet package.Workbook.Worksheets.Add(客户清单); // 设置表头 worksheet.Cells[1, 1].Value 客户名称; worksheet.Cells[1, 2].Value 所在城市; worksheet.Cells[1, 3].Value 联系人; // ... 填充数据 return package.GetAsByteArray(); } }如果项目预算有限NPOI 是更安全的选择——完全开源免费而且功能覆盖了绝大多数导出需求。我后来为了规避授权风险把项目里的导出组件全部替换到了 NPOI。如果你正在评估新项目直接选 NPOI 可以省去后续的合规隐患。4.4 .NET Framework 3.5 环境问题这个项目在部署过程中还踩过环境相关的坑。客户的服务器是 Windows Server 2016上面默认安装了 .NET Framework 4.x 运行时但旧版业务系统依赖 3.5。我在部署新系统时发现框架冲突导致进程崩溃排查后发现是两个框架版本并行时的程序集加载问题。这里有一个通用经验.NET Framework 3.5 和 4.x 是可以在同一台机器上共存的它们是互相独立的运行时。但 ASP.NET 应用程序池需要显式指定使用哪个版本配置错了就会报Could not load file or assembly之类的异常。如果你遇到的是服务器上安装 .NET Framework 3.5 时报错代码 0x80072f8f网络连接类错误这个通常是因为系统更新服务连不上微软服务器。在用 Windows Server 的“添加角色和功能”安装 .NET Framework 3.5 时可以指定备用源路径指向本地 Windows 镜像文件中的\sources\sxs目录绕开在线下载这个环节。# 使用 Windows Server 2016 镜像安装 .NET Framework 3.5 DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:D:\sources\sxs这类基础环境问题看着和业务代码无关但如果不处理好整个部署流程都会卡住。我的建议是在项目的部署文档里显式记录每个服务器角色的运行时版本要求省得每次换服务器、加环境都要从头踩一遍坑。4.5 GridView 的 jQuery 增强如果你还在用 ASP.NET WebForms 开发内部系统那你一定绕不开 GridView 控件。它虽然有强大的服务端事件机制但前端交互能力很弱——不支持排序动画、不支持前端分页、不支持行内编辑。我当时遇到的需求是客户列表要实现前端侧的无刷新排序而且要带下拉筛选效果。解决方案是引入 jQuery 插件 DataTables配合 GridView 的渲染结果做增强处理。$(document).ready(function () { $(#customerGridView).DataTable({ pageLength: 50, order: [[0, asc]], language: { search: 搜索客户:, lengthMenu: 每页显示 _MENU_ 条, info: 共 _TOTAL_ 条记录当前第 _PAGE_ 页 }, columnDefs: [ { orderable: false, targets: [5, 6] } // 操作列不可排序 ] }); });这里有一个特别注意的地方GridView 渲染出来的表格里操作列编辑、删除按钮的索引可能不固定如果增加隐藏列列索引会变化必须在上面代码里准确指定。一次性配置好之后用户体验提升非常明显——客户列表的翻页、搜索、排序都变成了毫秒级的响应。5. 常用功能模块的实现细节5.1 全局搜索业务方提了一个很朴素的需求“我想快速找到某个客户能不能直接一个搜索框搞定”听起来简单但实现起来要考虑的问题并不少搜索范围是客户名称还是包含联系人姓名搜索条件是精确匹配还是模糊匹配搜索结果按什么排序我最终实现的全局搜索是输入关键词同时匹配客户名称、联系人姓名、联系电话三个字段按客户名称的拼音首字母排序结果中高亮显示匹配的关键词。这个功能用好了销售每天可以省下很多翻列表找客户的时间。5.2 跟进日历视图另一个被高频使用的功能是跟进日历。销售日常工作的核心是“今天该联系谁”也就是系统里设置了下次跟进时间的客户。我实现了一个月历视图按日期展示所有到了跟进节点的客户点击日期能看到当天待跟进的客户列表勾选完成之后自动移动到下一天或下周。这个功能的业务价值在于它把 CRM 从“记录系统”变成了“工作驱动系统”。销售每天打开系统第一眼看到的是今天该干什么而不是一堆死数据。5.3 数据看板管理层最关心的不是某个客户跟得怎么样而是整个团队的业绩健康度。数据看板我做了三个维度本周新增客户数、本周成单金额、当前各阶段漏斗分布。展示在系统登录后的首页让管理者一打开系统就能掌握全局状态。这里要提到一个从实际运营中得来的经验看板上的指标不要超过五个。五项以内的指标管理层能消化吸收超过五项就容易变成“数字摆设”——看起来丰富实际没有人真的会逐个关注每一项。6. 从项目中学到的经验与建议6.1 先理解业务再做技术这个项目给我最大的一个教训是技术人做业务系统最大的风险往往不是技术方案选错而是根本不理解业务方真正需要什么。我第一版 CRM 系统在功能上做得特别“全”客户管理、订单管理、合同管理、售后管理全塞进去了结果上线后数据录入率不到 30%。后来跟销售一线的人深聊才发现他们最痛的点不在于功能少而在于“每天要花大量时间做重复录入”。所以第二版我重点做了几个能减少重复操作的功能客户快速录入、最近联系人自动带出等数据录入率才渐渐到了 80% 以上。所以我的建议是动手写代码之前至少要花一个礼拜贴身观察目标用户的工作流。这看起来效率很低但比起写出一个没人用的系统来这点时间太值了。6.2 版本迭代的节奏控制客户的反馈节奏往往是“刚上线要求稳定稳定之后要求新功能”。面对业务方提出的大量改动需求我的经验是分级处理——零散小改动改字段、调样式直接在当前迭代做跨模块的新需求报表重构、新增流程排进下个迭代战略性需求移动端、数据对接另立项目做调研和规划。有些开发人员习惯把需求一口气全做完再上线这在 CRM 这类业务系统里是大忌。因为 CRM 的很多需求是模糊的不上线跑两周你根本不知道这个功能到底合不合理。快速小步迭代、让用户尽早用起来才是更高效的产品推进方式。6.3 关于 .NET 技术栈的一点看法写完这个项目我对 .NET 技术栈有了更深的体会。ASP.NET 在开发企业级业务系统时依然是非常能打的选择尤其是后端管理类系统——类库丰富、稳定成熟、部署简单团队上手速度也快。虽然国内互联网圈子现在讨论更多的是 Go 和 Java但广大传统企业和政企事业单位的存量系统里.NET 的身影依旧非常多这个生态不会很快消失。如果你还有余力我建议往 ASP.NET Core 方向深入学习特别是它的依赖注入系统、中间件管道模型以及和前端工程化配合的能力。这是一条更长远的路线技术价值也会更高。7. 写在最后的实操建议如果让我给后来者一个建议那就是做 CRM 系统一定要先想清楚“要给谁用、解决什么问题”再做“怎么用更合适的技术实现它”。技术只是手段业务价值才是系统的存续命脉。最后分享一个小技巧在系统里埋一个轻量级的埋点统计比如记录每个登录用户每天在系统里做了哪些操作、在最常用的几个功能上停留了多久。这个数据在系统上线半年后会给你非常宝贵的改进方向——你会发现有些你以为没人用的功能其实被高频使用而有些精心设计的功能却成了摆设。数据不会说谎用它来引导产品走向往往比拍脑袋决策靠谱得多。
