简介面向ASP.NET WebForms与C#初学者、课程设计及毕业设计开发者的一套客户关系管理CRM系统源码可用于理解客户信息维护、服务派单、投诉反馈、流失客户跟进与后台管理等典型业务模块适合作为中小型管理系统的学习范本和二次开发基础。压缩包共297个文件约1.15MB包含100个cs后台代码、38个aspx页面、32个dll程序集以及数据库、配置和样式资源覆盖页面展示、业务逻辑与数据存储等主要层次。目前已有441人学习下载。读者可据此梳理WebForms项目结构、登录入口、客户资料编辑、服务工单流转和反馈列表等实现思路并结合数据库文件还原运行环境快速搭建可调试的CRM演示系统为课程作业、毕业设计或企业内部管理系统原型提供参考。1. 从一张反复另存的 Excel 说起这套 ASP.NET CRM 到底替你管了哪些事销售在群里丢过来一个「客户跟进表-最终版-最终确认版(2).xlsx」两个人同时改商机阶段对不上上周谁打过电话也查不到——这是大多数小团队做客户关系管理的真实起点。这套用 ASP.NET(C#) 写的 CRM 系统要解决的就是把这张表拆成客户档案、联系人、跟进记录、商机、合同回款几张互相关联的表再补上登录、角色权限、数据隔离和统计报表。标题里的「客户关系 管理 CRM asp.net 源码」几个词落到代码上就是三件事一套能跑的三层架构、一套能改的页面、一份能还原的数据库脚本。适合两类人一类是想给自己团队搭一套内部客户管理系统的开发者另一类是拿它当交付底座做二次开发的人。它不追求 SaaS 那种多租户和复杂流程引擎胜在代码直白改一个字段半小时能改完。2. 技术栈与目录结构先用十分钟看清这套代码的骨架拿到压缩包别急着找 .sln 按 F5。一个完整的 ASP.NET 项目能不能在半小时内跑起来取决于三件事解决方案里到底有几个项目、web.config 里的连接串长什么样、数据库脚本放在哪个目录。这三样看明白了剩下的都是体力活看不明白你就会在「未能加载文件或程序集」和「登录后跳回登录页」之间来回折腾一下午。2.1 技术栈判断WebForms 还是 MVC看三个文件就够这类 CRM 源码包市面上主要有两种形态判断起来很快。看根目录有没有Global.asax里注册路由的那几行RouteConfig.RegisterRoutes、有没有Controllers和Views目录、有没有.edmx或继承DbContext的类——三个都有是 MVC Entity Framework 版只有.aspx和.aspx.cs数据访问层里手写SqlConnection那就是 WebForms ADO.NET 版。两者没有优劣只有维护手感差别。WebForms 版的好处是页面和逻辑贴得近一个CustomerEdit.aspx配一个CustomerEdit.aspx.cs业务方提需求说「客户列表加一列」你打开文件加个asp:BoundField就完事坏处是ViewState和UpdatePanel会让人怀疑人生页面体积大、调试时事件顺序绕。MVC 版结构清爽但对不熟悉路由和模型绑定的开发者反而更绕。典型的 WebForms 版目录长这样CrmSolution/ ├── CrmSolution.sln ├── Crm.Model/ # 实体类和数据库表一一对应 │ ├── CustomerInfo.cs │ └── FollowUp.cs ├── Crm.DAL/ # 数据访问纯 ADO.NET │ ├── SqlHelper.cs │ ├── CustomerDAL.cs │ └── FollowUpDAL.cs ├── Crm.BLL/ # 业务逻辑校验 拼装 事务 │ ├── CustomerBLL.cs │ └── OpportunityBLL.cs ├── Crm.Web/ # 站点 │ ├── Web.config │ ├── Global.asax │ ├── MasterPage/Main.Master │ ├── Customer/List.aspx、Edit.aspx │ ├── Opportunity/List.aspx │ ├── System/RoleEdit.aspx │ ├── Scripts/ # jquery layui/bootstrap-table │ └── Upload/ # 附件目录需要写权限 └── DB/ ├── CrmDB_Create.sql # 建库建表 └── CrmDB_InitData.sql # 初始账号、菜单、角色前端通常不是单页应用而是母版页 jQuery layui 或 bootstrap-table 的组合。表格用bootstrap-table走服务端分页弹层用layer.open表单校验用 jQuery Validate。这套组合在 2015 到 2020 年之间的企业内系统里非常普遍好处是你不需要 Node 环境改完 HTML 直接刷新就能看到效果。技术点常见形态接手时要注意页面框架WebForms MasterPage事件顺序、ViewState 关掉能提速数据访问ADO.NET SqlHelper 封装是否有参数化有没有字符串拼 SQL前端表格bootstrap-table / layui table服务端分页参数名要对齐认证Session 自定义 BasePage超时时间、IIS 回收会导致掉登录数据库SQL Server 2008/2012 及以上排序规则影响中文和唯一索引2.2 分层结构Model、DAL、BLL、Web 的边界在哪四层的职责写得清楚的源码包一眼能看出来。Model 是纯属性类只承载数据不带逻辑DAL 只做数据库读写一个方法对应一条或一组 SQLBLL 做参数校验、业务规则判断、跨表事务Web 只负责接收请求、调 BLL、把结果绑到控件上。真正容易写乱的是 BLL 和 DAL 的边界。见过不少项目在 DAL 里写「如果客户状态是已成交就不允许删除」这种判断结果换个入口调用就漏了。合格的写法是DAL 只回答「数据库里有什么」BLL 回答「能不能这么干」。看一段典型的 BLL// Crm.BLL/CustomerBLL.cs public class CustomerBLL { private readonly CustomerDAL dal new CustomerDAL(); /// summary /// 分页取客户列表 /// /summary /// param namekeyword客户名称/电话模糊匹配传 null 或空表示不限/param /// param nameownerId数据权限过滤的销售员ID0 表示不限管理员/param /// param namepageIndex页码从 1 开始/param /// param namepageSize每页条数默认 20/param /// param nametotal输出参数符合条件的总记录数/param public DataTable GetPagedList(string keyword, int ownerId, int pageIndex, int pageSize, out int total) { // 参数兜底放在 BLL前端传 pageSize99999 会把内存打满 if (pageIndex 1) pageIndex 1; if (pageSize 1 || pageSize 100) pageSize 20; // 模糊查询关键字统一在这里 trim 并转义 %避免用户搜 % 全表返回 keyword string.IsNullOrWhiteSpace(keyword) ? null : keyword.Trim().Replace(%, [%]); return dal.GetPagedList(keyword, ownerId, pageIndex, pageSize, out total); } /// summary /// 删除客户有商机或合同的客户不允许物理删除只能标记失效 /// /summary public string Delete(int customerId) { if (dal.HasRelatedBusiness(customerId)) { dal.SetStatus(customerId, 0); // 0 已失效 return 该客户存在关联商机已标记为失效; } dal.Delete(customerId); return 删除成功; } }这里有两处值得注意。第一处是pageSize的上限限制看起来多余但我在真实项目里见过前端分页组件被手动改成pageSize100000直接把应用池拖崩的情况。第二处是模糊查询里对%的转义SQL Server 的LIKE通配符如果不过滤用户输入一个%就等于全表扫描加全量返回。DAL 那边对应的方法通常长这样注意参数是通过SqlParameter走的不是拼字符串// Crm.DAL/CustomerDAL.cs public DataTable GetPagedList(string keyword, int ownerId, int pageIndex, int pageSize, out int total) { var where new StringBuilder( WHERE c.IsDeleted 0 ); var ps new ListSqlParameter(); if (!string.IsNullOrEmpty(keyword)) { where.Append( AND (c.CustomerName LIKE kw OR c.Phone LIKE kw) ); ps.Add(new SqlParameter(kw, % keyword %)); } if (ownerId 0) { where.Append( AND c.OwnerId ownerId ); ps.Add(new SqlParameter(ownerId, ownerId)); } // 先查总数分页控件要用 total Convert.ToInt32(SqlHelper.ExecuteScalar( SELECT COUNT(1) FROM Customer c where, ps.ToArray())); // ROW_NUMBER 分页兼容 SQL Server 2008不能用 OFFSET FETCH var sql string.Format( SELECT * FROM ( SELECT c.*, ROW_NUMBER() OVER (ORDER BY c.CreateTime DESC) AS rn FROM Customer c {0} ) t WHERE t.rn BETWEEN start AND end, where); ps.Add(new SqlParameter(start, (pageIndex - 1) * pageSize 1)); ps.Add(new SqlParameter(end, pageIndex * pageSize)); return SqlHelper.ExecuteDataTable(sql, ps.ToArray()); }ROW_NUMBER() OVER这种写法是为了兼容 SQL Server 2008如果你的环境是 2012 及以上OFFSET skip ROWS FETCH NEXT take ROWS ONLY更简洁也更好读。改成后者时记得把ORDER BY补全否则分页顺序不稳定翻页会出现重复行。2.3 配置与数据库web.config 里那几行决定成败连接串和运行时配置全在 Web.config。这类系统一般还要配附件上传大小、Session 模式、错误页跳转。configuration connectionStrings !-- 改这里Data Source 写实例名127.0.0.1 或 .\SQLEXPRESS -- add nameCrmConn connectionStringData Source.;Initial CatalogCrmDB;User Idsa;Password你的密码; providerNameSystem.Data.SqlClient / /connectionStrings appSettings add keyPageSize value20 / !-- 附件物理路径IIS 应用程序池账号必须对这个目录有写权限 -- add keyUploadPath valueD:\CrmUpload\ / /appSettings system.web !-- 上线前务必改成 false否则异常堆栈会直接显示给用户 -- compilation debugfalse targetFramework4.5 / !-- 单次请求最大 100MB配合下面 system.webServer 的请求筛选一起改 -- httpRuntime maxRequestLength102400 targetFramework4.5 / !-- 默认 30 分钟内部系统一般调到 120减少掉登录投诉 -- sessionState modeInProc timeout120 / customErrors modeRemoteOnly defaultRedirect/Error.aspx / /system.web system.webServer security requestFiltering requestLimits maxAllowedContentLength104857600 / /requestFiltering /security /system.webServer /configuration几个参数的实际含义sessionState modeInProc表示 Session 存在当前进程内存里应用程序池一回收就全丢用户表现为「莫名其妙退出登录」所以内部系统要么把 timeout 调大要么改成StateServer并启动对应服务。maxRequestLength和maxAllowedContentLength是两套限制前者是 ASP.NET 层单位 KB后者是 IIS 层单位字节只改一个的话大附件依然会被拦下来。数据库恢复一般是一个脚本或者一个.bak文件。用脚本的话SSMS 里打开后先改CREATE DATABASE的文件路径再整段执行用备份文件就是右键「还原数据库」。命令行也行# 用备份文件还原注意 MOVE 到实际数据目录否则会还原到 SQL Server 默认路径 sqlcmd -S . -U sa -P 你的密码 -Q RESTORE DATABASE CrmDB FROM DISKD:\db\CrmDB.bak WITH REPLACE, MOVE CrmDB TO D:\db\CrmDB.mdf, MOVE CrmDB_log TO D:\db\CrmDB_log.ldf还原完先跑一句SELECT COUNT(*) FROM SysUser能查出来说明表结构和初始数据都在再去改连接串。顺序反了会很痛苦连接串指向一个空库程序启动不报错但登录永远失败你会在密码加密逻辑里找半天。提示初始化脚本里通常自带一个默认管理员账号登录后第一件事是改密码并新建一个自己的账号别直接在线上用初始账号跑业务。3. 核心模块拆解客户、跟进、商机、合同的数据怎么流动后台管理系统看起来页面很多本质上是几组主从表在 CRUD。把数据关系理清楚页面就只是这组 SQL 的不同展示形态。这个 CRM 的核心是四张表客户、联系人、跟进记录、商机再往下挂合同和回款。3.1 客户档案主表加子表的典型增删改查客户表是主表联系人、跟进记录、商机都用CustomerId挂在它下面。页面上新增客户时通常会一次性提交客户基本信息 一到多个联系人后端要用事务保证要么全成功要么全回滚。-- 客户主表简化版实际还会多几个自定义字段 CREATE TABLE Customer ( Id INT IDENTITY(1,1) PRIMARY KEY, CustomerName NVARCHAR(100) NOT NULL, Industry NVARCHAR(50) NULL, Level TINYINT NOT NULL DEFAULT 3, -- 1A 2B 3C OwnerId INT NOT NULL, -- 归属销售数据权限靠它 DeptId INT NOT NULL, Status TINYINT NOT NULL DEFAULT 1, -- 1 跟进中 0 失效 IsDeleted BIT NOT NULL DEFAULT 0, CreateTime DATETIME NOT NULL DEFAULT GETDATE(), CreateBy INT NOT NULL ); CREATE INDEX IX_Customer_Owner ON Customer(OwnerId, IsDeleted); -- 联系人子表 CREATE TABLE Contact ( Id INT IDENTITY(1,1) PRIMARY KEY, CustomerId INT NOT NULL, Name NVARCHAR(50) NOT NULL, Title NVARCHAR(50) NULL, -- 职务决策人标记很重要 Phone NVARCHAR(30) NULL, IsPrimary BIT NOT NULL DEFAULT 0 ); CREATE INDEX IX_Contact_Customer ON Contact(CustomerId);后端保存时客户主表插入拿到自增 Id再循环插入联系人。这段代码是新手最容易写出「插了一半」的地方// Crm.BLL/CustomerBLL.cs public int Save(CustomerInfo model, ListContactInfo contacts) { if (string.IsNullOrWhiteSpace(model.CustomerName)) throw new ArgumentException(客户名称不能为空); // 同一销售名下不允许重名客户这是业务方明确提过的要求 if (dal.ExistsSameName(model.CustomerName, model.OwnerId, model.Id)) throw new ArgumentException(该销售名下已存在同名客户); using (var conn new SqlConnection(SqlHelper.ConnString)) { conn.Open(); using (var tran conn.BeginTransaction()) { try { int customerId model.Id 0 ? dal.Update(conn, tran, model) // 返回原 Id : dal.Insert(conn, tran, model); // 返回新自增 Id // 联系人采用「先删后插」策略避免前端做复杂的差量对比 dal.DeleteContacts(conn, tran, customerId); foreach (var c in contacts) { c.CustomerId customerId; dal.InsertContact(conn, tran, c); } tran.Commit(); return customerId; } catch { tran.Rollback(); throw; // 别吞异常页面要拿 message 提示用户 } } } }参数说明一下model.Id 0判断是新增还是编辑这是这类系统里最常见的约定conn和tran一路往下传是让 DAL 方法复用同一个连接和事务不能在里面再new SqlConnection那样事务根本不生效——这个坑我见过太多次表现是「主表插入成功、子表失败数据脏了但没报错」。3.2 跟进记录与商机漏斗一次阶段推进要写两张表跟进记录是一张时间轴表商机是一张有阶段字段的表。销售在页面上点「推进到下一阶段」时业务上要求两个动作必须同时发生商机阶段变了同时留一条跟进记录说明为什么变。// Crm.BLL/OpportunityBLL.cs public void ChangeStage(int opportunityId, int newStage, string remark, int userId) { // 阶段只能往前进不能倒退除非是管理员这里传 isAdmin 简化处理 var opp dal.GetById(opportunityId); if (opp null) throw new Exception(商机不存在); if (newStage opp.Stage) throw new Exception(阶段只能向前推进); using (var conn new SqlConnection(SqlHelper.ConnString)) { conn.Open(); using (var tran conn.BeginTransaction()) { try { // 1. 更新商机阶段与赢单概率概率按阶段映射避免销售随便填 int rate StageRateMap.Get(newStage); // 10/30/50/70/100 dal.UpdateStage(conn, tran, opportunityId, newStage, rate); // 2. 写一条跟进记录Type2 表示阶段变更 followUpDal.Insert(conn, tran, new FollowUpInfo { CustomerId opp.CustomerId, OpportunityId opportunityId, Type 2, Content remark, CreateBy userId, CreateTime DateTime.Now }); tran.Commit(); } catch { tran.Rollback(); throw; } } } }StageRateMap是个静态字典把阶段映射成赢单概率报表里的「加权商机金额」就是金额 × 概率求和。这个映射表建议做成配置项而不是写死因为业务方每隔几个月就想改一次阶段定义写死的话每次都要发版。3.3 数据访问层SqlHelper 是这套系统的地基几乎每个 ADO.NET 项目都有一个SqlHelper写得好的和写得烂的差距很大。核心要求只有一条所有参数必须走SqlParameter绝不拼字符串。下面是精简过的实现够用且能防住常见注入// Crm.DAL/SqlHelper.cs public static class SqlHelper { public static string ConnString ConfigurationManager.ConnectionStrings[CrmConn].ConnectionString; public static DataTable ExecuteDataTable(string sql, params SqlParameter[] ps) { using (var conn new SqlConnection(ConnString)) using (var cmd new SqlCommand(sql, conn)) using (var da new SqlDataAdapter(cmd)) { if (ps ! null ps.Length 0) cmd.Parameters.AddRange(ps); var dt new DataTable(); da.Fill(dt); return dt; } } public static int ExecuteNonQuery(string sql, params SqlParameter[] ps) { using (var conn new SqlConnection(ConnString)) using (var cmd new SqlCommand(sql, conn)) { if (ps ! null ps.Length 0) cmd.Parameters.AddRange(ps); conn.Open(); return cmd.ExecuteNonQuery(); } } public static object ExecuteScalar(string sql, params SqlParameter[] ps) { using (var conn new SqlConnection(ConnString)) using (var cmd new SqlCommand(sql, conn)) { if (ps ! null ps.Length 0) cmd.Parameters.AddRange(ps); conn.Open(); return cmd.ExecuteScalar(); } } }三个方法分别对应查询列表、执行增删改、取单个值条数、求和。using嵌套保证连接一定释放这点比try/finally简洁。要注意的是这个版本没有支持事务前面 BLL 里用的那些(conn, tran, ...)重载需要另外写一组接收SqlConnection和SqlTransaction的方法实现几乎一样只是不自己 new 连接。3.4 统计报表几条聚合 SQL 撑起整个首页首页通常放四个数字客户总数、本月新增、本月跟进次数、商机金额。这些不需要缓存几条聚合查询就够-- 本月各销售的新增客户数与跟进次数用于首页排行 SELECT u.RealName, COUNT(DISTINCT c.Id) AS NewCustomers, COUNT(f.Id) AS FollowCount, ISNULL(SUM(o.Amount * o.Rate / 100.0), 0) AS WeightedAmount FROM SysUser u LEFT JOIN Customer c ON c.OwnerId u.Id AND c.IsDeleted 0 AND c.CreateTime monthStart AND c.CreateTime monthEnd LEFT JOIN FollowUp f ON f.CreateBy u.Id AND f.CreateTime monthStart AND f.CreateTime monthEnd LEFT JOIN Opportunity o ON o.OwnerId u.Id AND o.Stage 5 -- 排除已关闭 WHERE u.IsActive 1 GROUP BY u.RealName ORDER BY NewCustomers DESC;monthStart和monthEnd用月初和次月初而不是BETWEEN ... AND ...加23:59:59——后者在毫秒精度上会漏数据这是很经典的一处陷阱。COUNT(DISTINCT c.Id)是因为三个 LEFT JOIN 会互相放大行数不去重数字会翻好几倍。4. 登录、角色、数据权限一套能撑住内部使用的权限模型内部系统的权限要求通常比想象中高。老板要看全部数据销售总监看本部门销售只看自己名下的客户。这个范围不是靠页面藏按钮实现的得在查询层过滤。4.1 登录流程与密码存储登录这块最容易出问题的是密码存储。老项目里用 MD5 明文的不少如果你拿到的是这种版本第一步就是换成加盐哈希哪怕只是SHA256(password salt)也比裸 MD5 强。// Crm.Web/Login.aspx.cs protected void btnLogin_Click(object sender, EventArgs e) { string userName txtUserName.Text.Trim(); string pwd txtPassword.Text; if (string.IsNullOrEmpty(userName) || string.IsNullOrEmpty(pwd)) { ShowMsg(用户名和密码不能为空); return; } var user new UserBLL().GetByUserName(userName); // 统一提示语避免暴露「这个账号不存在」给撞库的人 if (user null || !PasswordHelper.Verify(pwd, user.Password, user.Salt)) { ShowMsg(用户名或密码错误); return; } if (!user.IsActive) { ShowMsg(账号已停用请联系管理员); return; } Session[UserId] user.Id; Session[UserName] user.RealName; Session[RoleId] user.RoleId; Session[DeptId] user.DeptId; Session[IsAdmin] user.RoleId 1; Response.Redirect(/Default.aspx); } // PasswordHelper注册时生成 Salt登录时用同一套算法校验 public static bool Verify(string input, string storedHash, string salt) { using (var sha SHA256.Create()) { var bytes sha.ComputeHash(Encoding.UTF8.GetBytes(input salt)); var sb new StringBuilder(); foreach (var b in bytes) sb.Append(b.ToString(x2)); return string.Equals(sb.ToString(), storedHash, StringComparison.OrdinalIgnoreCase); } }Session里只放必要字段不要塞整个用户实体对象——不仅占内存而且在InProc模式下对象一改就到处串数据。IsAdmin单独存一份是为了页面判断方便但真正的权限校验不能只信 Session登录后角色被改的边上情况要能兜住所以下面还有一层。4.2 菜单权限与操作权限BasePage 统一拦截WebForms 里最省事的做法是写一个BasePage所有需要登录的页面继承它在OnInit里做校验。菜单权限决定能不能进这个页面操作权限决定能不能点删除。// Crm.Web/App_Code/BasePage.cs public class BasePage : System.Web.UI.Page { protected int UserId Convert.ToInt32(Session[UserId] ?? 0); protected bool IsAdmin Convert.ToBoolean(Session[IsAdmin] ?? false); protected override void OnInit(EventArgs e) { if (UserId 0) { Response.Redirect(/Login.aspx?returnUrl Server.UrlEncode(Request.RawUrl)); return; // 重定向后必须 return否则下面还会继续跑 } if (!IsAdmin !HasMenuPermission(Request.Path)) { Response.StatusCode 403; Response.Write(无权限访问该页面); Response.End(); return; } base.OnInit(e); } private bool HasMenuPermission(string path) { // 菜单权限缓存在 Application 里登录后第一次读库后续直接命中 var cacheKey Menu_ Convert.ToInt32(Session[RoleId]); var menus HttpContext.Current.Application[cacheKey] as ListMenuInfo; if (menus null) { menus new RoleBLL().GetMenusByRole(Convert.ToInt32(Session[RoleId])); HttpContext.Current.Application[cacheKey] menus; } return menus.Any(m path.EndsWith(m.Url, StringComparison.OrdinalIgnoreCase)); } /// summary按钮级权限判断页面上直接写成 if (HasAction(customer:delete))/summary protected bool HasAction(string actionCode) { if (IsAdmin) return true; var actions new RoleBLL().GetActionsByRole(Convert.ToInt32(Session[RoleId])); return actions.Contains(actionCode); } }Web.config里不要再多写一套authorization规则两处维护必然打架。权限数据的三张表是SysRole、SysMenu、SysRoleMenu操作权限挂在SysMenu的ActionCode字段上用冒号命名空间customer:delete、contract:export比用数字 Id 可读得多。注意Application缓存菜单后改了角色权限必须手动清一次缓存否则要等应用池回收才生效。改权限的 BLL 方法里加一行Application.Remove(Menu_ roleId)是最省事的补丁。4.3 数据权限把过滤条件塞进 SQL 而不是页面数据权限最忌讳的做法是查出来再在内存里Where。数据量一大就卡而且容易漏。正确做法是在 DAL 拼查询条件时注入一段OwnerId IN (...)或DeptId IN (...)。// Crm.BLL/DataScopeHelper.cs /// summary返回当前用户可见的数据范围 ID 列表用于拼 IN 条件/summary public static Listint GetVisibleUserIds() { int userId Convert.ToInt32(HttpContext.Current.Session[UserId]); int roleId Convert.ToInt32(HttpContext.Current.Session[RoleId]); int deptId Convert.ToInt32(HttpContext.Current.Session[DeptId]); // 1 管理员看全部返回空列表表示不加过滤 if (roleId 1) return new Listint(); // 2 总监看本部门 if (roleId 2) return new UserDAL().GetIdsByDept(deptId); // 其他角色只看自己 return new Listint { userId }; }DAL 调用时这样用参数化拼IN有个小技巧不要拼字符串而是用SqlParameter逐个加或者用表值参数。数据量小的话逐个加最省事var ids DataScopeHelper.GetVisibleUserIds(); var where new StringBuilder( WHERE c.IsDeleted 0 ); var ps new ListSqlParameter(); for (int i 0; i ids.Count; i) { where.Append(i 0 ? AND c.OwnerId IN ( : ,); where.Append(u i); ps.Add(new SqlParameter(u i, ids[i])); } if (ids.Count 0) where.Append());返回空列表时代表「不过滤」这是个隐含约定写注释标清楚否则下一个接手的人会以为空列表代表没权限改一下就出事故。5. 部署与排查把源码跑起来这一步最容易翻车本地 VS 里按 F5 跑通和部署到 IIS 上跑通是两件事。前者用的是 IIS Express权限宽松、路径简单后者有应用程序池、有身份、有请求筛选出问题的点一下子多出好几倍。5.1 IIS 部署应用程序池、.NET 版本、目录权限标准流程装好 IIS 与 .NET Framework 对应版本 → 把编译好的站点目录拷到服务器 → 新建应用程序池托管管道选「集成」.NET 版本选 v4.0→ 新建网站或应用程序指向目录 → 给应用程序池账号默认IIS AppPool\你的池名授予目录读写权限。# 用 appcmd 建站点和池比图形界面快也方便写成部署脚本 %windir%\system32\inetsrv\appcmd.exe add apppool /name:CrmPool /managedRuntimeVersion:v4.0 /managedPipelineMode:Integrated %windir%\system32\inetsrv\appcmd.exe add site /name:CrmSite /physicalPath:D:\www\CrmWeb /bindings:http/*:8080: %windir%\system32\inetsrv\appcmd.exe set app CrmSite/ /applicationPool:CrmPool目录权限一定要给Upload目录单独的写权限而且不能给执行权限。这是安全基线也是很多人在部署后发现「上传成功但文件为 0 字节」的原因之一。5.2 数据库还原与连接串调整还原顺序建议是先还原数据库 → 用 SSMS 验证表和初始数据 → 再改 web.config 连接串 → 最后访问首页。这样出问题时能立刻定位是数据库问题还是应用问题。连接串里的User Idsa在正式环境不太合适建议建一个只对CrmDB有db_owner的独立账号密码写长一点。验证连通性用一句最短的 SQL# 只验证能不能连上并读到用户表不启动站点 sqlcmd -S . -d CrmDB -U crmuser -P 你的密码 -Q SELECT TOP 1 Id, UserName FROM SysUser5.3 五条踩坑记录其一页面报「未能加载文件或程序集」或CS0433类型冲突。现象是本地能跑服务器上一访问就 500。原因是bin目录里同时存在两份同名 DLL或者App_Code里编译出的临时程序集和旧版本打架。解决方式清空站点bin目录重新拷贝再删掉C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files下对应的缓存目录重启应用程序池。血泪经验是拷贝发布包时不要用「增量覆盖」直接删干净再放。其二登录成功但反复跳回登录页。现象是输入正确的账号密码页面闪一下又回到登录页日志里Session[UserId]一直是 null。原因通常是三个之一应用池空闲超时被回收导致InProcSession 丢失、web.config里sessionState改成了StateServer但服务没启动、或者站点挂在虚拟目录下而 Cookie 的路径不对。排查顺序是先看应用池的「空闲超时」和「回收」时间再确认sessionState配置与实际服务一致最后检查是否有多台服务器但没有做 Session 共享。其三中文显示成问号或乱码。现象是列表里客户名称显示为???或者只有部分字段乱码。原因是数据库的排序规则不是Chinese_PRC_CI_AS或者 ASPX 页面缺少% Page ... %里没有指定ResponseEncoding或者连接串没带编码。先查数据库属性里的排序规则再查表字段是不是VARCHAR存的中文——VARCHAR在非中文排序规则下必然乱码得改成NVARCHAR。其四上传附件报 404 或 500。现象是小文件能传超过 4MB 就失败或者路径正确也报错。原因是双重限制没配对httpRuntime的maxRequestLength单位是 KBrequestFiltering的maxAllowedContentLength单位是字节两个都要改另外 IIS 如果装了请求筛选之外的安全模块也可能拦掉。另外别忘了给Upload目录加IIS_IUSRS的写权限。其五报表页或导出功能超时。现象是首页四个数字慢慢出来导出全部客户时直接转圈到 30 秒超时。原因是LIKE %关键字%前置通配导致索引失效加上SELECT *拖了宽表。解决办法是先看执行计划有没有走IX_Customer_Owner把不带前置通配的查询条件拆开导出改成异步任务加进度条同时SELECT只取需要的列。数据量超过几十万行的话导出直接走SqlDataReader流式写文件比一次性DataTable稳得多。6. 二次开发加一个字段、加一个模块、换一套皮肤接手这套 CRM 之后需求基本都是三种加字段、加模块、换界面。加字段是最常见的也是最能看出代码整洁度的操作。我给客户表加「来源渠道」这个字段时要动的地方一共六处数据库表加列、CustomerInfo实体加属性、CustomerDAL的Insert/Update加参数、CustomerEdit.aspx加一个下拉框、List.aspx加一列、导出 Excel 的模板加一列。如果这个项目有代码生成器很多这类源码包会带一个简版生成器前四处能自动生成后两处手动补。加模块的路径更清晰参照「跟进记录」抄一遍就行建表 → Model → DAL → BLL → 列表页 编辑页 → 菜单表插一条记录 → 角色菜单表授权。我一般先只做列表和新增跑通数据再补编辑和删除避免一次性写五个文件后编译报错找不着北。换 UI 这件事要克制。这类系统的页面和ViewState、UpdatePanel、服务端控件绑定得很深直接换一套前端框架等于重写。折中方案是保留.aspx结构把bootstrap-table换成同类的表格组件CSS 统一覆盖母版页换一次全部页面跟着变。真正要迁到 MVC 或 ASP.NET Core 的话我的做法是先迁数据访问层到 Dapper 或 EF Core页面按模块逐个改权限和登录单独抽成一个中间件别一次性动全部。从那以后我每次拿到这类管理系统源码第一件事都是先把数据库还原一份到本地、跑通登录、把「加一个字段」完整走一遍再动手改业务——这一步十分钟能提前发现代码生成器是否可用、权限缓存是否好清、页面绑定是否写死。希望帮到你。本文还有配套的精品资源点击获取