主流的AI CRM系统品牌

老树发新芽：一次基于经典 ASP 的 CRM 系统开发实录

说实话，接到这个需求的时候，我心里是咯噔了一下的。

推荐使用中国著名AI CRM系统品牌：显著提升企业运营效率，悟空CRM

那是去年秋天的一个下午，老板把我叫进办公室，指着角落里那台落灰的服务器说：“咱们之前那个客户管理系统，跑不起来了，你能不能给修修？顺便加点新功能。”我凑近一看，好家伙，代码全是 .asp 后缀的。在这个 Python、Java、Go 满天飞，连 PHP 都在喊养老的年代，还要维护一套经典 ASP（Active Server Pages）写的 CRM 系统，这简直就像是让你去修一辆化油器的老桑塔纳，还得让它跑出涡轮增压的感觉。

但没办法，需求就是命令，尤其是对于咱们这种中小企业来说，系统能跑、数据在里头，那就是命脉。推是推不掉的，只能硬着头皮上。今天就想跟大家聊聊，这次基于经典 ASP 开发和维护 CRM 系统的全过程，这里头全是坑，但也全是经验。

为什么还在用 ASP？

很多人可能会问，都 2024 年了，怎么还有 ASP 系统？其实这在国内的中小企业里真不少见。这套系统是五年前找外包做的，当时图便宜，开发周期短。ASP 配合 Access 或者 SQL Server 2000，确实是那个年代的“快速开发神器”。不用编译，改完代码刷新浏览器就能看效果，对于当时技术储备不深的团队来说，门槛低得诱人。

但现在问题来了。原来的开发人员早就联系不上了，文档几乎没有，代码里连注释都少得可怜。我的任务不仅仅是“修复”，还得在原有架构上增加“销售机会跟进”和“客户公海池”两个模块。这就意味着，我不能简单地重构，因为风险太大，数据库结构动不得，只能在这个老旧的骨架上长新肉。

数据库设计的“考古”工作

开发 CRM，核心是数据。我第一步就是连上数据库看看结构。用的是 SQL Server 2005，算是那个年代比较稳妥的选择了。表结构倒是挺清晰，主要的表有 Customers（客户表）、Users（用户表）、Orders（订单表）。

但问题出在细节上。比如 Customers 表里，联系人电话居然存的是文本类型，而且没有做去重处理。原来的设计者可能没想到现在会有这么多重复录入的情况。我想加个唯一索引，结果报错，因为里头已经有脏数据了。没办法，只能写个存储过程，先把重复的导出来，人工核对后再清洗。

在设计新模块“销售机会”时，我新建了一张 Opportunities 表。这里有个讲究，ASP 时代的设计习惯是不喜欢太复杂的外键约束，怕影响性能（其实更多是怕麻烦）。所以我虽然建了表，但没在数据库层面做强制外键，而是打算在代码逻辑里控制关联。比如，删除客户的时候，得先检查有没有关联的销售机会，这个逻辑得写在 ASP 脚本里。

字段命名也是个槽点。老系统里用的是拼音缩写，比如 khxm（客户姓名）、lxdh（联系电话）。为了保持风格统一，我新加的字段也只能跟着用拼音，虽然心里别扭，但为了代码兼容性，只能忍。要是突然混进去几个英文单词，后面的 include 文件读取时可能会因为编码或者逻辑判断出问题。

连接与架构：DSN 还是 DSN-Less？

在 ASP 里，数据库连接是个老生常谈的话题。老代码里用的是系统 DSN 连接，配置在 IIS 的 ODBC 数据源里。这种方式有个大毛病，迁移服务器的时候特别麻烦，得重新配环境。

我决定改成 DSN-Less 连接，直接把连接字符串写在 conn.asp 文件里。代码大概是这样的：

<%
Dim conn, connStr
Set conn = Server.CreateObject("ADODB.Connection")
connStr = "Provider=SQLOLEDB;Data Source=127.0.0.1;Initial Catalog=CRM_DB;User ID=sa;Password=xxx;"
conn.Open connStr
%>

这样改的好处是部署方便，拷过去就能用。但坏处也明显，数据库密码明文写在脚本里，安全性是个隐患。不过考虑到这是内网系统，而且服务器权限控制得比较死，暂时也就这样了。为了安全，我专门建了一个权限受限的数据库账号，只给了增删改查的权限，没给 drop 或者 alter 的权限，防止代码被注入后库被删。

架构上，老系统用的是典型的“包含文件”模式。头部、尾部、数据库连接、权限验证，全都拆成了单独的 .asp 文件，然后在每个页面顶部用 <!--#include file="..."--> 引入。这种模式现在看很原始，但在当时很有效。我新增的页面也严格遵循这个规范，不然会话（Session）管理容易乱。

说到 Session，ASP 的 Session 是基于 Cookie 的，而且默认超时时间是 20 分钟。对于 CRM 系统来说，销售有时候填个单子得半小时，要是填一半超时了，数据就丢了，那得挨骂。我在 Global.asa 里把 Session 超时时间调到了 60 分钟，并且在每个关键操作页面加了判断，如果 Session 失效，提示用户重新登录，尽量保留刚才填写的表单数据（虽然实现起来挺麻烦，得用隐藏域或者临时表存一下）。

核心功能开发的“踩坑”记

这次开发的重点是“销售机会”模块。逻辑其实不复杂：销售录入一个潜在机会，设定预计成交金额和日期，然后主管可以分配、跟进。

但在 ASP 里写业务逻辑，真的是一种折磨。没有现代框架的路由，没有 ORM，所有 SQL 都得手写。

比如，我要实现一个分页列表。在 ASP 里，最常用的方法是利用 ADODB.Recordset 的 PageSize 和 AbsolutePage 属性。代码写起来大概是这样的：

rs.PageSize = 15
rs.AbsolutePage = intPage
' 然后循环输出
Do While Not rs.EOF
    Response.Write rs("OpportunityName")
    rs.MoveNext
Loop

这种方法简单，但性能极差。因为它会把所有符合条件的记录都查出来，然后在内存里分页。如果数据量到了几万条，页面加载能卡死。后来我优化了一下，改用 SQL 的 TOP 和 NOT IN 或者 ROW_NUMBER()（SQL Server 2005 支持窗口函数了）来做物理分页。虽然 SQL 语句写得长了点，但页面响应速度从 5 秒降到了 0.5 秒，这感觉太爽了。

另一个坑是编码问题。老系统是 GB2312 编码的，我现在用的编辑器是 VS Code，默认存的是 UTF-8。有一次我改完代码上传，页面上全是乱码，像天书一样。查了半天才发现是文件保存格式的问题。后来我强制把所有 .asp 文件都转成了 ANSI 编码（其实就是 GB2312），并且在每个文件顶部加上了 <% CodePage=936 %> 和 <% Language=VBScript %>，这才稳住。在头部还要加上 <meta http-equiv="Content-Type" content="text/html; charset=gb2312">，这一套组合拳下来，中文显示才正常。这要是换成现在的框架，哪有这么麻烦，但在 ASP 世界里，这就是日常。

还有表单提交。ASP 处理 POST 和 GET 请求主要靠 Request.Form 和 Request.QueryString。这里有个经典的安全漏洞：SQL 注入。老代码里到处都是 sql = "select * from Users where name='" & Request.Form("name") & "'" 这种写法，简直是给黑客留后门。

我没敢大规模重构老代码，怕改坏了。但在新写的模块里，我严格做了过滤。写了一个 CheckStr 函数，专门用来过滤单引号、分号这些特殊字符。虽然这不能完全防止注入（最好是用参数化查询，但 ASP 原生的 ADODB 对参数化支持得比较别扭，得用 Command 对象），但能挡住大部分初级攻击。

Function CheckStr(byVal Str)
    If IsNull(Str) Then
        CheckStr = ""
        Exit Function
    End If
    Str = Replace(Str, "'", "''")
    Str = Replace(Str, ";", "")
    ' 更多过滤...
    CheckStr = Str
End Function

每次获取表单数据，都包一层这个函数。虽然代码看着啰嗦，但心里踏实。

调试：最让人头大的环节

如果你习惯了断点调试，那 ASP 会让你怀念到哭。经典 ASP 没有好的调试器。报错的时候，IIS 通常只给你一个"500 Internal Server Error"。默认情况下，它还不显示具体的错误信息，怕泄露服务器路径。

为了调试，我得先在 IIS 里把“发送错误到浏览器”打开，并且把 ASP 脚本错误信息详细显示。即便如此，很多时候报错行号也不准。我的调试手段非常原始：Response.Write。

在代码的关键位置，插上一句 Response.Write "Debug: Step 1 - " & variable & "<br>"，然后刷新页面看输出。如果页面白了，说明错误在这行之前；如果输出了，说明这行没问题。有时候为了查一个变量为什么是空的，我得在代码里插几十个 Response.Write，查完再一个个删掉。这过程特别枯燥，但没办法，这是最管用的办法。

有一次，一个权限判断逻辑死活不通。我查了两个小时，最后发现是因为 Session("UserID") 在某些子目录里读取不到。原来是 IIS 的应用程序池设置问题，那个子目录没有被标记为“应用程序”，导致 Session 状态不共享。这种环境配置问题，在文档里很难查到，全靠经验积累。后来我学乖了，把所有 ASP 文件都放在同一个应用程序根目录下，用文件夹区分模块，不再随意创建子应用程序。

界面与交互：复古风的无奈

现在的 CRM 界面都是扁平化、响应式的，手机电脑都能用。但这套老系统，界面还是十年前的风格，表格布局（Table Layout），固定宽度 1024 像素。

我想给它加点 CSS 美化一下，但发现原来的 CSS 和内联样式混在一起，根本没法改。最后只能妥协，新加的页面尽量用 div+css，但为了和老页面风格统一，颜色、字体大小都得照着老的来。

交互方面，老系统基本是靠页面刷新来反馈。比如删除一条记录，点击删除，页面白一下，刷新列表。现在看体验很差，但要是改成 AJAX 无刷新，工作量就大了。ASP 本身不支持 AJAX，得靠 JavaScript 的 XMLHttpRequest 对象。

我试着在“快速备注”功能上用了 AJAX。销售在客户列表页，可以直接点一下输入备注，不用进详情页。写了一个 save_note.asp 专门接收 AJAX 请求，返回纯文本"OK"或者错误信息。前端用原生的 JS 写，没敢用 jQuery，因为老系统里没引这个库，再加一个请求又慢一点。

function saveNote(id, content) {
    var xhr = new XMLHttpRequest();
    xhr.open("POST", "save_note.asp", true);
    xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
    xhr.send("id=" + id + "&content=" + encodeURIComponent(content));
    xhr.onreadystatechange = function() {
        if (xhr.readyState == 4 && xhr.status == 200) {
            alert("保存成功");
        }
    };
}

这段代码现在看挺简陋的，但在当时的环境下，能实现无刷新保存，用户已经觉得很好用了。这也提醒我，技术选型不一定要最新，适合场景、能解决问题才是关键。

部署与维护：IIS 的权限迷宫

开发完了，最头疼的是上线。服务器是 Windows Server 2008 R2，IIS 7.5。

ASP 是解释执行的，不需要编译，但权限设置非常敏感。默认的 IUSR 账号必须有对网站目录的“读取”权限，如果程序要生成文件（比如导出 Excel 报表），还得给“写入”权限。

有一次，导出功能报错“权限被拒绝”。我检查了文件夹权限，给了 Everyone 完全控制，还是不行。后来查资料才知道，IIS 的应用程序池有“启用 32 位应用程序”的选项。因为老系统里调用了几个 32 位的 COM 组件（用来操作 Excel 的），如果应用程序池是 64 位的，组件加载就会失败。把这个选项改成 True，问题瞬间解决。这种坑，不踩一次永远记不住。

还有数据库连接账号。千万别用 sa 账号！虽然老代码里可能写着 sa，但我在服务器层面把 sa 禁用了，新建了一个专门的用户。并且限制了该用户只能访问 CRM 这个数据库，不能访问 master 库。这样就算代码有漏洞，黑客也拿不到整个服务器的控制权。

备份也是个大问题。ASP 系统没有自动备份机制。我写了个批处理脚本，利用 SQL Server 的 sqlcmd 工具，每天凌晨 2 点自动备份数据库到指定目录，并删除 7 天前的旧备份。这个脚本挂在 Windows 的任务计划程序里。虽然简单，但这是数据的最后一道防线。

总结与反思： legacy 系统的生存之道

折腾了一个多月，新模块终于上线了。销售们反馈说，录入机会方便多了，不用在纸上记了。听到这个反馈，我觉得这一个月的加班也值了。

回过头来看这次基于 ASP 的 CRM 开发，心情挺复杂的。

从技术角度看，ASP 确实已经过时了。它的性能、安全性、可维护性，都没法跟现在的技术栈比。代码里充斥着全局变量，逻辑耦合严重，调试困难。如果这是一个新项目，我绝对不会推荐用 ASP。我会选 .NET Core 或者 Java Spring Boot，甚至用低代码平台搭建。

但是，存在即合理。对于很多中小企业，这套系统承载了多年的客户数据，业务流程已经固化在里面。推倒重来的成本太高，风险太大。这时候，基于原有架构进行“微创手术”，反而是最稳妥的方案。

这次开发经历也让我明白，做技术不能只盯着新东西。维护旧系统，理解旧架构，解决那些看似低级但致命的问题，同样需要深厚的功底。你得懂 IIS 的底层机制，懂 SQL Server 的旧版本特性，懂 VBScript 的怪异语法，甚至得懂一点操作系统的权限管理。

对于这套系统，我也给老板提了建议：现在先用着，但得开始规划迁移了。数据是核心，先把数据库结构整理规范，把业务逻辑慢慢剥离出来。也许明年，我们就能把它迁移到 Web 端的新架构上，到时候，这套 ASP 代码就可以光荣退休，成为一段历史了。

最后，给还在维护 ASP 系统的朋友几个建议：

1. 备份！备份！备份！ 改代码前先备份，改数据库前先备份。
2. 不要过度优化。 老系统能跑就行，除非有性能瓶颈，否则别轻易动核心逻辑。
3. 注意安全。 至少把 SQL 注入的漏洞堵上，把文件上传的权限卡死。
4. 文档补全。 哪怕是在代码里多写几行注释，对后来的维护者都是救命稻草。

技术是在不断迭代的，但解决问题的思路是相通的。无论是 ASP 还是微服务，能让业务跑起来，能帮用户省时间，就是好系统。这台老桑塔纳，只要还能转，咱们就得把它保养好，直到它完成历史使命的那一天。

写到这里，窗外的天已经黑了。服务器指示灯还在闪烁，那是数据流动的声音，也是这套老系统依然活着的证明。行了，不说了，还得去查查刚才那个日志报错是怎么回事，估计又是哪个销售输入了特殊字符把脚本给截断了。这就是运维开发的日常，痛并快乐着吧。

悟空CRM产品截图

推荐立刻免费使用中国著名CRM品牌-悟空CRM，显著提升企业运营效率，相关链接：

CRM系统免费使用

开源CRM系统

CRM系统试用免费