简介：一份基于asp.net(C#)的客户关系管理系统CRM源码包，面向正在学习WebForms开发或需要客户管理流程参考的开发者，覆盖客户编辑、服务调度、归档列表、流失管理、反馈处理等功能模块，可帮助理解CRM常见业务逻辑与页面间数据传递方式。包内共297个文件，约1.15MB，以100个.cs后端逻辑、38个.aspx页面、32个.dll组件、31个.pdb调试符号为主，同时包含41个.gif、14个.jpg等界面素材，以及.mdf/.ldf/.db数据库文件与.config配置文件，便于还原系统运行环境；sln和csproj解决方案文件可直接组织项目结构。项目目录按登录、客户维护、调度服务、流失管理等典型模块组织，结构清晰，可按模块对照学习aspx页面与cs代码的对应关系。目前已有441人学习下载，适合作为ASP.NET入门项目或课程设计的参考案例，读者可直接查看源码、页面与数据库表结构，快速梳理客户关系管理系统的设计与实现思路，也能为二次开发或毕业设计提供基础。
1. 先看这套 asp.net 客户关系管理源码能解决什么：从线索到回款的完整闭环
给销售团队找客户关系管理（CRM）系统，很多人第一反应是买正版 SaaS 按坐席付费，一年下来预算不少，定制需求还得排队等排期。其实一份靠谱的 asp.net（C#）CRM 源码就能解决启动问题——它基于传统 WebForms 三层结构，数据落在 SQL Server 里，页面层负责交互、业务层处理规则、数据层统一访问数据库，覆盖客户档案、跟进记录、商机、合同、回款统计这条完整闭环。我第一次拆这套系统时，花了不到半天把数据库跑起来，随后接手的同事也能在源码里快速定位要改的方法。适合两种人：想尽快给公司内部搭一套 CRM 的开发者，以及想学着读别人 .NET 工程的老手。
2. 架构地图：三层结构 + 模块拆分，先看懂再动手
2.1 技术选型：为什么是 WebForms + SQL Server 而不是 MVC/Core
看到是 WebForms 而不是 MVC 或 Core，先别急着下“过时”的结论。在中小企业内部系统里，WebForms 的存量非常大，尤其是跑在 Windows 服务器 + IIS 的老环境上，这种组合维护成本低、部署快。页面用 .aspx 保存服务端控件，开发增删改查的速度比前后端分离快不少，对内部管理系统来说，开发效率优先级高于架构先进性。
这套 CRM 用 SQL Server 作为数据库非常自然。ASP.NET 与 SQL Server 同生态，备份恢复、权限管理、定时作业都能在 SSMS 图形界面里完成，交接给新人的学习曲线平缓。业务逻辑则在中间层做，页面不直接拼 SQL，而是调用 BLL 里的 Manager 类，Manager 再调 DAL 访问数据库。这样改一个查询条件，不需要在十几个页面里翻来翻去。
你可能会问为什么不用 ASP.NET Core。原因很直接：原项目是 .NET Framework 时代的产物，迁移 Core 意味着把服务端控件全部重写，路由、依赖注入、认证方式全部要换。对一份以“跑起来、改得动”为目标的源码来说，在当前结构上叠加新功能，比推到重来成本低得多。
2.2 目录结构逐层解读：从 .aspx 到 DAL 的调用链
拿到源码包后先看解决方案结构，我通常按“页面层 – 业务层 – 数据层 – 实体层”拆开理解。下面是一个典型的 CRM 工程布局：
CRM.sln ├─ CRM.Web │ ├─ Login.aspx # 登录页 │ ├─ Main.aspx # 主框架页 │ ├─ Customer │ │ ├─ List.aspx # 客户列表 + 分页查询 │ │ ├─ Edit.aspx # 新增/编辑客户 │ │ └─ Follow.aspx # 跟进记录管理 │ ├─ Contract │ │ ├─ ContractList.aspx │ │ └─ ContractEdit.aspx │ ├─ Report │ │ └─ SalesStat.aspx # 销售统计报表 │ ├─ assets/ # CSS、图片、脚本 │ └─ web.config ├─ CRM.BLL │ ├─ CustomerManager.cs │ ├─ UserManager.cs │ └─ ContractManager.cs ├─ CRM.DAL │ ├─ DbHelper.cs # 数据库访问封装 │ ├─ CustomerDAL.cs │ └─ UserDAL.cs ├─ CRM.Model │ ├─ CustomerInfo.cs │ └─ UserInfo.cs └─ SQL ├─ CRM_DB.sql # 建库脚本 └─ InitData.sql # 初始账号、菜单、字典数据页面层的 .aspx 文件按业务模块分文件夹，文件名基本能和功能对上号。业务层每个实体对应一个 Manager，DAL 对应一个 XXXDAL。调用链是：页面点击按钮 → .aspx.cs 里的触发方法 → 调用 BLL 的某个 Manager → Manager 调 DAL → DAL 通过 DbHelper 执行参数化 SQL → 返回 DataTable 或实体。
新手第一次改功能时，别看到什么就改什么。先定位页面文件名，再看页面里面绑定了哪个 Manager 方法，顺着方法进 DAL，这样改起来不会漏掉权限或状态校验。老手可能会直接打开 DAL 看 SQL，但最好还是从页面倒推一遍，确认这条链路上有没有被别的地方引用的公共方法。
2.3 数据库设计：客户、跟进、商机、合同/回款如何串起来
CRM 的核心不是一张大表，而是几张互相有外键关系的业务表。常见设计是用户表、角色表、菜单表做权限基础，客户表做主体，跟进记录、商机、合同、回款都挂在客户 ID 下面。客户表记录归属人 OwnerId，跟进记录记录每次沟通内容和下次联系时间，商机表记录预计金额和阶段，合同表关联回款计划。理解这个主从关系，报表统计时就知道 join 哪些表、按哪个状态字段过滤。
下面建表脚本是这套项目里最典型的两张表，主表与跟进子表：
CREATE TABLE dbo.Customers ( Id INT IDENTITY(1,1) PRIMARY KEY, Name NVARCHAR(100) NOT NULL, Level TINYINT DEFAULT 0, -- 0潜在 1普通 2重要 Source NVARCHAR(50), -- 渠道来源 Phone NVARCHAR(30), OwnerId INT, -- 归属销售，用于数据权限 FollowStatus TINYINT DEFAULT 0, -- 0待跟进 1跟进中 2已成交 3已流失 CreatedAt DATETIME DEFAULT(GETDATE()), UpdatedAt DATETIME ); CREATE TABLE dbo.FollowRecords ( Id INT IDENTITY(1,1) PRIMARY KEY, CustomerId INT NOT NULL, Content NVARCHAR(500), -- 跟进内容 NextContactDate DATETIME, -- 下次联系时间 CreateBy INT, -- 跟进人 CreatedAt DATETIME DEFAULT(GETDATE()), CONSTRAINT FK_Follow_Customer FOREIGN KEY(CustomerId) REFERENCES dbo.Customers(Id) );参数说明：Customers.Level 用 TINYINT 存等级状态，比直接存中文字符串节省空间，也方便做下拉框绑定；FollowStatus 关联报表漏斗统计；OwnerId 是数据权限的关键字段，列表页默认只显示当前销售自己的客户，管理员角色可以看全部。FollowRecords 是一对多的子表，每次跟进插入一条记录，不覆盖旧数据，这样才能留下完整沟通历史。
你在二次开发时最常动的就是这两张表。加字段要注意：如果将来要用 ORM（比如 EF），表结构和实体类要同步更新，否则运行期会报列无效。字段命名建议避免关键字，比如 Name、Level 在 SQL Server 里不算保留字，但有些版本会有隐性冲突，更稳妥的做法是在字段前加前缀，比如 CustomerName、CustomerLevel。
3. 核心代码拆解：从登录、客户查找到跟进写入的完整链路
3.1 入口拦截与登录校验：BasePage 怎么做到未登录就跳转
这套 CRM 没有引入复杂的权限框架，用的是最直接的 Session + 角色校验。为了避免每个页面重复写判断，公共基类 BasePage 接管所有页面初始化，页面只要继承它，就自动完成登录检查和菜单权限校验。
public class BasePage : System.Web.UI.Page { protected override void OnInit(EventArgs e) { // 先判断 Session 里有没有登录用户 if (Session["UserId"] == null) { Response.Redirect("~/Login.aspx"); return; } // 再校验当前角色是否有权访问这个页面路径 if (!MenuRightService.HasRight( Convert.ToInt32(Session["RoleId"]), Request.CurrentExecutionFilePath)) { Response.StatusCode = 403; Response.End(); return; } base.OnInit(e); } }逻辑说明：OnInit 在 Page_Load 之前执行，所以登录拦截能提前触发。Session["UserId"] 在登录成功后写入，如果为空说明会话过期或未登录，直接重定向到登录页。MenuRightService.HasRight 接收两个参数，第一个是角色 ID，第二个是当前请求的页面相对路径，内部去菜单权限表匹配。
这里的参数是角色级权限，也就是同一角色的人能访问的页面范围相同。如果业务要求“销售只能看自己的客户，经理能看全组的客户”，这种按数据行过滤的权限不能靠页面路径匹配实现，得在查询 SQL 里加 OwnerId 条件，后面改造章节会展开讲。这个基类设计最省事的地方在于：新增页面只要继承 BasePage，就不会出现忘写登录校验导致后台页面裸奔的问题。
3.2 登录逻辑：参数化查询 + 密码散列存储
登录页面 .aspx.cs 里做的事是：读取用户名和密码，查用户表，比对散列后的密码，成功则写入 Session。注意密码不是明文存储，常见的做法是 MD5 或 SHA256 加盐后入库。下面这段代码是这套源码里的核心写法：
protected void btnLogin_Click(object sender, EventArgs e) { string sql = @"SELECT UserId, UserName, RoleId FROM dbo.Users WHERE UserName = @u AND Password = @p AND IsLocked = 0"; SqlParameter[] ps = new SqlParameter[] { new SqlParameter("@u", SqlDbType.NVarChar, 50) { Value = txtName.Text.Trim() }, new SqlParameter("@p", SqlDbType.NVarChar, 100) { Value = EncryptHelper.Md5(txtPwd.Text.Trim()) } }; DataTable dt = DbHelper.ExecuteDataTable(sql, ps); if (dt.Rows.Count > 0) { Session["UserId"] = dt.Rows[0]["UserId"]; Session["RoleId"] = dt.Rows[0]["RoleId"]; Response.Redirect("Main.aspx"); } else { lblMsg.Text = "用户名或密码错误，或账号已禁用"; } }逻辑说明：查询条件里带了 IsLocked = 0，账号被锁定时直接登录失败，不用等到进系统再判断。SqlParameter 数组把用户输入当作参数传给 SQL，不走字符串拼接，能有效防注入。密码入库前通过 EncryptHelper.Md5 转成哈希，数据库里看不到明文密码。
这里有个踩坑点：很多同学接手后会图省事把参数化改成 $"select * from users where name='{txtName.Text}'"，这在内部工具里也许能跑通，但这是绝对不应该碰的写法。字符拼接一旦被注入，代价是整个客户数据泄漏。保持参数化写法，是这套工程最值得保留的习惯。
3.3 客户列表分页与搜索：ROW_NUMBER 和条件拼装
客户列表页既要分页，又要支持关键字搜索和归属人过滤。这套源码的做法是在 DAL 层拼条件 SQL，用 ROW_NUMBER 做分页，然后用第二个语句查总数。下面拆开看关键部分：
public DataTable GetPage(int pageIndex, int pageSize, string keyword, int ownerId, out int total) { string sql = @"SELECT * FROM ( SELECT ROW_NUMBER() OVER(ORDER BY c.CreatedAt DESC) AS rownum, c.*, u.UserName AS OwnerName FROM dbo.Customers c LEFT JOIN dbo.Users u ON c.OwnerId = u.UserId WHERE (@keyword = '' OR c.Name LIKE '%' + @keyword + '%') AND (@ownerId = 0 OR c.OwnerId = @ownerId) ) t WHERE t.rownum BETWEEN (@pageIndex - 1) * @pageSize + 1 AND @pageIndex * @pageSize"; SqlParameter[] ps = new SqlParameter[] { new SqlParameter("@keyword", SqlDbType.NVarChar, 100) { Value = keyword ?? "" }, new SqlParameter("@ownerId", SqlDbType.Int) { Value = ownerId }, new SqlParameter("@pageIndex", SqlDbType.Int) { Value = pageIndex }, new SqlParameter("@pageSize", SqlDbType.Int) { Value = pageSize } }; string countSql = @"SELECT COUNT(1) FROM dbo.Customers WHERE (@keyword = '' OR Name LIKE '%' + @keyword + '%') AND (@ownerId = 0 OR OwnerId = @ownerId)"; total = Convert.ToInt32(DbHelper.ExecuteScalar(countSql, ps)); return DbHelper.ExecuteDataTable(sql, ps); }逻辑说明：外层查询用 ROW_NUMBER 按创建时间倒序排号，里层条件用 @keyword 为空串或模糊匹配名字，@ownerId 为 0 时不过滤归属人，为具体值时只看当前销售名下客户。total 参数返回记录总数，供页面上的分页控件计算总页数。
这种写法最大的好处是参数可复用。keyword、ownerId、pageIndex 来自页面查询参数，页面点击搜索按钮后再调用 Manager.GetPage，把数据绑定到 GridView 或 Repeater 上刷新。如果后续要增加按客户等级筛选，只需在 SQL 中再加一个 @level 参数和对应条件。唯一要注意的是，LIKE '%' + @keyword + '%' 在数据量大时索引会失效，百万级客户表建议换全文索引，或者退一步用前置模糊匹配。
4. 本地跑通：从数据库脚本到 IIS 发布的完整步骤
4.1 环境准备：装什么、不装什么
跑这套 CRM 不需要 Docker，也不需要 Linux，一台 Windows 机器足够。需要提前装的是 Visual Studio（社区版即可）、SQL Server 数据库、SQL Server Management Studio。打开解决方案文件前，先确认 VS 里装了“.NET 桌面开发”和“ASP.NET 和 Web 开发”工作负载，否则打开项目会提示缺程序集。
我一般会把项目先放到一个纯英文路径下，比如 D:\Projects\CRM，避免中文目录导致编译期一些文件引用问题。如果系统里只装了高版本的 VS，打开旧版 sln 时 VS 会提示做一次升级转换。这里建议先复制一份工程备份再做转换，因为升级有可能会改动项目文件格式，甚至破坏某些页面设计器文件。
4.2 初始化数据库：跑脚本而不是等 MDF
源码包里通常会带两种东西：完整的 .mdf 数据库文件，或者建库脚本。我建议优先使用 SQL 脚本重建数据库，因为 .mdf 附加容易受文件权限影响，而且初始数据库里可能带有一堆脏数据。流程是：在 SSMS 里新建查询，打开 SQL/CRM_DB.sql 执行，再执行 InitData.sql 插入初始账号、角色菜单和基础字典数据。
如果你是命令行习惯，也可以用 sqlcmd 执行：
sqlcmd -S . -i "D:\Projects\CRM\SQL\CRM_DB.sql" sqlcmd -S . -i "D:\Projects\CRM\SQL\InitData.sql"参数说明：-S 指定服务器实例名，点号表示本机默认实例；-i 指定脚本文件路径。执行完成后，刷新数据库列表，确认出现 CRM_DB 数据库，然后打开表目录检查 Users 表里是否已有初始账号。初始账号的密码通常是初始化脚本里写死并哈希过的，脚本注释里一般会标注明文密码，留意别删掉。
4.3 修改 web.config 连接字符串与调试运行
数据库就绪后，在 VS 中打开解决方案，按 F5 运行前，先看 web.config 里的连接字符串是否指向本机数据库。原始配置可能写的是开发服务器地址或者 SA 账号，需要改成当前环境能连上的：
<connectionStrings> <add name="CrmDb" connectionString="Data Source=.;Initial Catalog=CRM_DB;Integrated Security=True;" providerName="System.Data.SqlClient" /> </connectionStrings>参数说明：Data Source 指定数据库实例名，点号表示本机默认实例，如果是命名实例要写成 .\SQLEXPRESS 或 机器名\实例名；Initial Catalog 是数据库名；Integrated Security=True 表示用当前 Windows 账号登录 SQL Server，如果你用的是 SQL Server 账号登录，就改成 User ID=sa;Password=你的密码。
接着按 F5，VS 会启动内置 IIS Express，打开登录页。如果首页直接报数据库连接错误，大概率是第 5 章里说的实例名或权限问题，先回 SSMS 用同一套配置手动测试连接。如果能弹出登录页，输入初始账号密码，即可进入主页面。
4.4 用一条业务路径验证部署是否正常
本地调试跑通后，至少要走完一条完整业务路径再做发布：登录系统 → 进入客户管理列表 → 新增一个测试客户 → 给客户添加一条跟进记录 → 查看销售统计报表。走这条路径能暴露三类问题：数据库写入权限、页面跳转路径、统计报表的数据过滤条件。某一步断掉，就顺着断点排查。
正式发布到 IIS 时，在 VS 里选择“发布”，发布到文件夹后打开 IIS 管理器，新建一个应用程序池指向 .NET Framework 4.0 集成模式，然后创建网站或虚拟目录指向发布目录。注意 bin 目录要一并发布，发布后确认应用程序池里的“加载用户配置文件”选项关闭，否则部分环境会报临时目录权限错误。发布完成后，用浏览器访问站点根路径，重新走一遍上面的验证业务路径。
5. 避坑记录：本机跑这套 CRM 最容易踩的 5 个坑
5.1 数据库附加失败：mdf 被占用或没有权限
现象：SSMS 附加数据库时报错“无法打开物理文件，操作系统错误 5（拒绝访问）”，或者附加成功后过一会数据库状态变成“可疑”。
原因：SQL Server 服务账号对 .mdf 和 .ldf 文件所在的目录没有写权限。日志文件无法写入时，数据库会进入可疑状态。另外，如果数据库已经在当前实例上附加过，再附加一次也会报文件已存在。
解决：先把数据库文件复制到非系统盘，右击文件属性，在安全里给 SQL Server 服务账号加“完全控制”权限。如果已经附加过，先通过分离数据库操作移除，再重新附加。对于可疑状态，最好的习惯是直接删掉这个库，用脚本重新生成一次，而不是去修复损坏的日志文件。
5.2 连接字符串实例名对不上
现象：页面打开时报“建立到服务器的连接时发生错误”，或者“在建立连接的握手期间发生错误”。
原因：web.config 里 Data Source 写的是本机默认实例，但 SQL Server 实际装在命名实例下，或者本机装了多个实例。数据源写错，SQL Server 客户端找不到目标实例。
解决：先在 SSMS 里用目标登录方式测试连接，复制连接对话框里实际用的服务器名到 web.config。如果是本机默认实例，写“.”或“localhost”；如果是命名实例，要写成 机器名\实例名；如果是远程服务器，写成 IP,端口。改完后记得回收一次 IIS 应用池，因为连接字符串被缓存在进程里，不回收的话旧配置不会生效。
5.3 登录成功后马上跳回登录页
现象：用户名密码输入正确，页面点击登录后一闪又回到 Login.aspx，像从没登录过一样。
原因：Session 丢失。最常见的原因是 IIS 应用程序池设置了空闲超时回收，或者站点配置了无 Cookie 会话模式，浏览器不保存会话 ID，刷新后 Session 就找不到了。还有可能是页面指令里设置了 EnableSessionState="False"。
解决：打开 web.config，确认 sessionState 配置为<sessionState mode="InProc" cookieless="UseCookies" timeout="20"></sessionState>。部署到 IIS 后，在应用程序池的高级设置里把“固定时间间隔”调大，或者改为 0 禁用定期回收。排查时先在登录成功后的代码里把 Session["UserId"] 值输出到页面上，能直观看出是没写入还是被清掉。
5.4 发布到虚拟目录后样式和图片全部丢失
现象：VS 调试时页面样式正常，发布到 IIS 虚拟目录后，页面只剩文字，CSS、图片、脚本全部 404。
原因：页面里引用的资源用的是相对路径，比如 images/style.css。当站点通过 /crm/Customer/List.aspx 这样的虚拟目录访问时，浏览器解析相对路径变成了 /crm/Customer/images/style.css，实际资源却在 /crm/assets 下，于是全部 404。
解决：把布局页或母版页里的资源引用统一改为绝对根路径，或者用 ResolveUrl 动态解析。常见的两条写法：
<link href="<%=ResolveUrl("~/assets/style.css") %>" rel="stylesheet" /> <script src="<%=ResolveUrl("~/assets/app.js") %>"></script>参数说明：ResolveUrl 会把“~/”解析成当前站点根路径，部署到虚拟目录时自动带上目录名前缀，这样无论应用挂在哪个位置，资源路径都不会错。发布前还应该检查发布输出目录里有没有 assets 文件夹，很多发布配置默认只包含程序集和页面文件，静态资源被漏掉了。
5.5 报表和图表页在不同机器上表现不一致
现象：同一套源码，在旧电脑上图表能正常显示，换新机器打开报表页一片空白，或者页面直接报错。
原因：老式 ASP.NET 项目里常见的图表控件依赖 web.config 里注册的 HttpHandler，如果发布时没有把 handler 配置一并更新，图表请求会被拦截。另一类情况是页面用了旧图表库，需要 Flash 插件支持，新浏览器默认禁用后图表自然不渲染。
解决：先检查 web.config 的 httpHandlers 节点里有没有 ChartImage.axd 相关配置，确认发布后的配置与开发环境一致。如果确认配置没问题但图表仍不显示，直接换开源前端图表组件，在页面里用 JavaScript 读取统计数据并渲染。这是成本最低的解法，还顺便摆脱了对旧插件和旧控件的依赖。
6. 拿到源码后怎么改造成自己的：以新增合同审批模块为例
二次开发的第一步不是写代码，而是把改造范围圈出来。假设公司要在现有 CRM 里加一个“合同审批”功能，让销售提交合同后由主管审批，审批通过才能进入回款阶段。这个功能涉及数据结构、权限菜单、页面逻辑三块，按下面的顺序推进。
先在数据库层加字段或建表。最省事的方式是在 Contract 表上增加 IsApproved TINYINT 字段，0 表示待审批，1 表示通过，2 表示驳回，再增加 ApproverId 审批人字段。如果希望保留审批历史，就建一张 ContractApprove 子表，记录每次审批人、审批结论和备注。加完字段后把建表脚本同步到 SQL 目录，别只改数据库不更新脚本。
然后是 DAL 和 BLL 层。在 ContractDAL 里写一个获取待审批合同的方法，条件就是 IsApproved = 0 AND ApproverId = 当前用户，再用 ContractManager 做业务包装。最后在 CRM.Web 下新增 Approval/List.aspx 和 Approval/Edit.aspx 两个页面，继承 BasePage，列表页用 GridView 绑定待审批合同，审批页提供通过或驳回按钮。菜单表里插入两条记录，并把权限分配给主管角色。
验证方法是登一个普通销售账号，确认他看不到审批菜单；再登主管账号，走一遍查看待审批列表、通过一份合同、回头确认合同状态变化的路径。一次改动跑通这条链路，基本不会出现漏改了权限或漏判状态导致的数据异常。从那以后我每次接手老 WebForms 项目，都强制走一遍“先改数据库脚本、再改 DAL、最后改页面”的顺序，改完至少登两个角色验证一遍，确认首页入口、列表、详情三步都通才收工。希望帮到你。
本文还有配套的精品资源，点击获取
