前段时间接手一个二手项目，客户丢过来一个压缩包，里面是一套武侠论剑题材的 ASP 网页游戏源码，回合制打怪、升级、装备、门派竞技一整套玩法都在。他原来的诉求很简单：改个皮，换个名字，挂到自己的服务器上跑起来。我打开一看，代码是十几年前的写法，ASP + Access，页面里到处是拼字符串的 SQL、混着 HTML 的 VBScript、以及大量<!--#include file="..."-->。这种东西现在没人教，网上搜到的教程要么只讲 IIS 安装，要么只讲某一处报错，凑不齐一条完整的落地路径。

这篇就按我实际走一遍的顺序来写：先让页面能打开、能登录，再回头把战斗、掉落、成长这些核心逻辑捋清楚，最后处理老架构躲不掉的并发、安全和性能问题。适合三类人看——手里正好有一套类似源码想跑起来的、想拿它当练手项目学 ASP 的、以及需要给这种老系统做二次开发但不知道从哪下手的。全文不涉及任何具体运营建议，只讲代码和环境。基础要求是会一点 VBScript、能看懂 SQL、会用 IIS 管理器；没有这些基础也能跟着走，遇到概念我会用生活化的说法解释。

1. 把老站点点亮：IIS 与 Access 环境的配置取舍

拿到源码第一步不是读代码，是让它先出个首页。这一步卡住的人最多，因为这套技术栈的环境配置有几个反直觉的地方，一不小心就陷在空白页里。

1.1 为什么"启用 32 位应用程序"是第一道门槛

Access 数据库在 ASP 里通过 OLE DB 提供程序访问，老源码用的基本都是Microsoft.Jet.OLEDB.4.0。这个驱动只有 32 位版本，从来没有出过 64 位。而现在服务器上的 IIS 默认跑在 64 位进程里，页面一执行到Server.CreateObject("ADODB.Connection")之后的Open，就会抛出"未找到提供程序。该程序可能未正确安装"这句经典报错。

很多人看到"未正确安装"就去重装 Office、重装 Access Runtime，折腾半天没用。正确做法是回到 IIS 管理器，找到站点对应的应用程序池，右键"高级设置"，把启用 32 位应用程序这一项从 False 改成 True，然后回收应用程序池。这一步的本质是让 w3wp.exe 以 32 位模式加载 Jet 驱动，不是装什么东西。

如果你手上这台机器确实只能跑 64 位，也不是没路走：装一个 64 位的 Access 数据库引擎，然后把连接字符串换成 ACE：

' 老的 Jet 写法 ' Conn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Server.MapPath("/data/game.mdb") ' 换成 ACE 之后的写法 Dim Conn, connStr Set Conn = Server.CreateObject("ADODB.Connection") connStr = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & Server.MapPath("/data/game.mdb") & ";Persist Security Info=False;" Conn.Open connStr

这里有个细节要注意：ACE 驱动对文件扩展名敏感，.mdb和.accdb都能开，但如果文件名后缀被改乱了（有些源码包里叫.asa或.dat来防止被直接下载），ACE 有可能识别失败，这时候要么改回.mdb，要么在连接串里加上Extended Properties显式声明。我个人更倾向于改回.mdb，然后在 IIS 里用请求筛选把这个后缀禁掉，安全性靠配置解决，别靠改后缀这种野路子。

1.2 目录权限与 .ldb 锁文件：500 错误的两个高频来源

环境配好之后，最常见的现象是首页能开、点登录就 500。这套源码的写法和现代框架不一样，它几乎所有状态都存在数据库里，登录要写、打怪要写、走路也要写，所以只要数据库文件没有写权限，任何一次提交都会挂。

权限要给两处，缺一不可：

用户身份用IIS_IUSRS（应用程序池标识是 ApplicationPoolIdentity 时，实际生效的是IIS AppPool\池名称，但给IIS_IUSRS授权在大多数默认配置下也能覆盖）。我一般两个都给上，省得排查。

注意：.ldb文件是 Access 的锁信息文件，正常情况下有人连接时存在、全部断开后自动消失。如果它一直不消失并且大小不变，多半是有个进程占着连接没关，或者上一次请求异常中断没走到Conn.Close。这种情况不用删文件，重启一下应用程序池最干脆。

另一个高频 500 来源是父路径。老源码里到处都是<!--#include file="../inc/config.asp"-->这种相对上级目录的引用，IIS 默认禁止父路径，需要在站点的 ASP 设置里把启用父路径打开。不打开的话，包含文件加载失败，页面直接报"Active Server Pages 错误 'ASP 0131'"。

1.3 别再对着空白页猜：把详细错误逼出来

IIS 默认对远程访问隐藏详细错误，只给一个"500 - 内部服务器错误"的通用页。本地调试时第一件事是把这个开关全部打开：

1. IIS 管理器里选中站点，打开"ASP"图标
2. "调试属性" → "将错误发送到浏览器" 设为 True
3. "编译" → "将详细 ASP 错误发送到浏览器" 设为 True
4. 站点的"错误页"里，把 500 那条的响应模式临时改成"详细错误"

改完之后再访问，报错行号和错误描述会直接打到页面上，比翻日志快十倍。这里提醒一句：这几项只在开发环境开，上线前一定要关回去，否则数据库路径、SQL 语句都会暴露给访问者。

还有一个隐蔽的坑——文件编码。VBScript 时代的中文源码一般是 GB2312 或 GBK 存的，拿现代编辑器一打开、一保存，很可能变成 UTF-8 带 BOM。BOM 出现在<!--#include-->文件开头时，会导致输出多出几个不可见字符，页面顶部凭空多出空白行，严重时Response.Redirect直接报"HTTP 头已发送"。我的处理习惯是用支持编码选择的编辑器，明确以 GB2312 打开、以 GB2312 保存，全程不碰 UTF-8。

2. 摸清源码骨架：目录布局与表结构里的历史包袱

环境通了之后不要急着改功能，先把目录和数据表看一遍。这套源码的组织方式很有代表性，看懂它，后面改任何功能都能快速定位到地方。

2.1 目录布局背后的分工逻辑

典型的目录结构大致是这样：

/ 站点根 /inc 公共包含文件（数据库连接、函数库、常量） /admin 后台管理 /images 素材 /data 数据库文件 /js 脚本 index.asp 首页/入口 login.asp 登录处理 main.asp 游戏主界面（框架页） map.asp 地图与移动 fight.asp 战斗处理 bag.asp 背包 ...

根目录那几十个.asp文件是核心，每个文件基本对应一个玩法动作，fight.asp里既有页面渲染也有提交处理，靠Request.Form有没有值来分支。这种"一个文件管一件事"的写法在当年很常见，优点是改起来直观，缺点是重复代码多——几乎每个文件开头都有一大段一模一样的登录校验。

/inc目录是整个系统的命脉，通常有这么几个文件：

• conn.asp：数据库连接，被几乎所有页面包含
• function.asp：公共函数，字符串处理、数值格式化、随机数、时间处理都在这里
• config.asp：全局常量，站点名、版本号、开关
• check.asp：登录态校验和权限判断

改这套东西的第一课，是先读function.asp。里面往往埋着很多业务约定，比如经验值怎么算、等级怎么映射、属性怎么取整。你不读它，改数值的时候会改出一堆对不上的地方。

2.2 五张核心表撑起全部玩法

Access 里的表不多，一般五张就能运转：

角色表是重中之重，几乎所有玩法都围绕它读写。这里有个很典型的设计：把当前气血、当前内力直接存在角色表里，而不是每次战斗时计算。好处是简单，坏处是任何一次异常退出都可能留下一个"血量为 0 但没死"的状态，需要专门的修复脚本。

战斗日志表在小型部署里往往长得飞快，一天几千场战斗就是几万行。Access 单表超过十万行之后查询会明显变慢，所以这张表要配一个定期清理的策略，保留最近七天的记录就够排查用。

2.3 Access 字段类型的三个隐形地雷

从 SQL Server 或者 MySQL 转过来的人，第一次用 Access 建表几乎必踩这三个坑：

第一是货币与整数。Access 里"货币"类型是定点小数，显示时会自动带货币符号或者两位小数，而代码里比较大小用的是数值。银两这种大数值用"长整型"更稳，上限二十一亿多，够用也不会出现浮点误差。如果原表用的是"单精度/双精度"，那么 1000000 + 1 有可能还是 1000000，因为它只有七位有效数字。

第二是是否型。Access 的"是/否"类型在 SQL 里其实是 -1 和 0，不是 1 和 0。老代码里WHERE 是否绑定 = 1这种写法永远查不到数据，得写= True或者= -1。这个坑不报错，只是默默地查空，很容易让人以为是数据丢了。

第三是时间。Access 的日期时间精度到秒，没有毫秒。如果业务里需要精确排序（比如按战斗时间倒序取最新一条），同一秒内产生的两条记录顺序是不确定的，得靠自增主键来兜底排序。

改表结构之前一定先备份.mdb文件，Access 的 ALTER TABLE 支持非常有限，改错字段类型经常直接丢数据，而且没有回滚。

3. 回合制战斗的完整链路：从点击到落库

战斗是这套源码里逻辑最密集的部分，也是二次开发改动最多的地方。搞清楚一次攻击的完整流程，等于掌握了整个游戏的运行节奏。

3.1 一次攻击请求要经过哪些环节

用户在页面上点"攻击"，fight.asp收到一个POST，里面带着目标 ID。接下来的执行顺序大致是：

' 1. 校验登录态（包含 check.asp） ' 2. 取攻击方角色数据 Set rsA = Conn.Execute("SELECT * FROM 角色表 WHERE 账号ID=" & Session("uid")) ' 3. 取防守方（怪物/NPC）数据 Set rsD = Conn.Execute("SELECT * FROM 怪物表 WHERE ID=" & CLng(Request.Form("mid"))) ' 4. 判定命中、计算伤害 ' 5. 更新防守方血量，判断是否死亡 ' 6. 若死亡则结算经验和掉落 ' 7. 更新攻击方数据（血量、经验、等级、背包） ' 8. 写战斗日志 ' 9. 输出结果页

关键在第 4 步和第 6 步。第 4 步的伤害公式一般长这样：

伤害 = 攻击方攻击力 * (1 + 随机浮动) - 防守方防御力 * 减伤系数

随机浮动的范围决定了战斗的"手感"，常见是 0.9 到 1.1。减伤系数不能设成 1，否则高防御怪会完全免疫，一般是 0.5 到 0.7，保证防御有用但不会无敌。伤害算完之后还要往下限兜一下，If 伤害 < 1 Then 伤害 = 1，否则会出现"打了半天不掉血"的死循环。

我在改动数值时踩过一个坑：老代码里所有属性都是整数，但伤害公式中间结果带了小数，直接赋回字段时 Access 会自动四舍五入。结果就是攻击力 105 和 106 的角色打出来的伤害完全一样，因为算完都变成同一个整数了。解决办法是在写回之前显式取整，把取整策略统一放在一处，别让数据库替你做决定。

3.2 成长曲线：等级和经验的关系怎么定

经验值的设计直接决定玩家多久能升一级。老源码里常见的是一个简单的幂函数：

升级所需经验 = 基础值 * 等级 ^ 1.8

指数取 1.8 左右是比较舒服的区间：早期升级快，后期逐渐拉长。如果取 2.0 就是标准平方，前期偏慢；取 1.5 后期又会太快，几十级之后升得飞起。这个值不是拍脑袋——你可以拿 Excel 拉一列，从 1 级到 60 级，看每级所需时间是否单调递增且不会在某一段突然陡增。

经验溢出也要处理。玩家一次打死怪拿了 5000 经验，只差 100 就升级，那么多出来的 4900 要留到下一级，不能直接抹掉。写法上是循环判断：

Do While rsRole("经验") >= GetNeedExp(rsRole("等级")) rsRole("经验") = rsRole("经验") - GetNeedExp(rsRole("等级")) rsRole("等级") = rsRole("等级") + 1 ' 升级奖励：加属性、加气血上限 Loop

这里必须用Do While而不是If，否则一次拿的经验太多就只能升一级，玩家会觉得"经验被吞了"。同时循环里要加一个保险，比如最多循环五十次，防止公式写错导致死循环把 CPU 拉满。

3.3 随机数播种：一个让所有玩家同时暴击的经典错误

VBScript 的Rnd是需要播种的，不播种的话每次页面加载产生的随机序列完全相同。这意味着第一个访问的人暴击了，接下来所有人都暴击，因为每次请求都是新进程上下文里重新开始。

正确写法是在需要随机的页面顶部调用一次：

Randomize ' 之后再用 Rnd Dim rate rate = Int((100 - 1 + 1) * Rnd + 1) ' 生成 1~100 的整数 If rate <= 15 Then ' 15% 暴击 End If

但Randomize不带参数时用的是系统计时器做种子，同一秒内的并发请求会拿到相同种子，还是会出现"一批人同时暴击"。更稳的做法是在function.asp里封装一个带额外熵的播种函数，把SessionID、时间、自增计数器混进去。不要小看这个细节，在竞技玩法里，同时暴击会直接引发公平性投诉。

提示：Access 里取随机记录不要用ORDER BY Rnd(id)，那个在大表上会全表排序，性能极差。改成先SELECT COUNT(*)拿总数，再用Int(Rnd * 总数)算出偏移量，配合TOP取一条。

4. 会话、并发与刷资源：老架构最脆弱的三处

功能和数值调顺之后，真正容易出事的不是逻辑，是并发。ASP + Access 这套组合在并发上的短板非常明显，必须提前想好对策。

4.1 Session 里该放什么、不该放什么

这套源码普遍把玩家 ID、昵称、权限等级放在Session里，这没问题。问题出在有些版本把整个角色对象序列化塞进 Session，包括气血、经验、背包列表。这么做会导致状态双份：Session 里一份，数据库里一份，两处不一致时以谁为准完全说不清。

我的做法是 Session 只放三个东西：账号 ID、角色 ID、权限标记。其余所有数值每次请求从数据库现取。多一次查询换来的是状态唯一，值得。Access 单条主键查询的开销很小，在几十人同时在线的量级上完全能接受。

Session 超时默认 20 分钟，这个值对网页游戏来说偏短，玩家挂机看个视频回来就得重新登录。可以在站点的 ASP 设置里调到 60 到 120 分钟，或者在每次请求时刷新Session.Timeout。但要注意，Session 多了会占内存，几千个会话同时存在时 IIS 内存占用会明显上升，别一口气调到一天。

还有一个容易被忽略的点：Session 和 Cookie 的绑定。老的登录校验大多只看Session("uid")有没有值，不看来源。如果站点和另一个站共用同一个域名，Session 会串。检查一下SessionID的 Cookie 作用域，必要时在global.asa里显式设置。

4.2 Access 没有行锁，抢怪时会发生什么

这是最要命的一条。SQL Server 可以用UPDATE ... WHERE 状态 = 0配合行锁保证只有一个事务能拿到这一行，Access 没有这个能力。两个玩家同时打同一只 BOSS，两边都读到了"血量 100"，各自算完伤害写回"血量 40"，实际上打了两次只扣了一次血，而且两边都认为自己打死了，都拿到了掉落。

可行的缓解办法有三层：

第一层是业务上避让。让每只怪物绑定到具体玩家（加一个归属角色ID字段），谁先触发谁占住，其他人看到的是"正在被挑战"。这个改造量最小，效果最直接。

第二层是靠更新语句的返回值判断。ADO 的Conn.Execute执行 UPDATE 之后，RecordsAffected会返回受影响行数。把状态判断写进 WHERE 条件，只有返回 1 才算抢到：

Conn.Execute "UPDATE 怪物表 SET 血量 = 血量 - " & dmg & " WHERE ID = " & mid & " AND 血量 = " & oldHp If Conn.Execute("SELECT @@IDENTITY").State = 0 Then ' 这里只是示意流程，实际用 RecordsAffected End If

真实写法是用Conn.Execute(sql, recordsAffected)拿到影响行数，等于 0 就说明在自己读取之后有人改过了，让玩家重试。这叫乐观锁，实现简单但需要前端配合"重试"提示。

第三层是减少并发窗口。把"读数据—算伤害—写回"这三步压缩到同一个页面请求内完成，中间不要有任何跳转或者等待。老代码里有的版本是先输出一段动画，再让浏览器自动跳转去结算，这中间的几百毫秒就是漏洞窗口。

4.3 三类典型的资源刷取漏洞

翻这类老源码，几乎每次都能找到以下几类问题，性质都一样：服务端信任了客户端的输入。

第一类是数量参数没校验。买药的时候前端传num=1，服务端就直接按 1 计算，但没人拦着改成num=-5。负数乘单价得到负的总额，扣钱变成了加钱。修法是所有涉及数量的参数一律CLng转型并判断范围，If num < 1 Or num > 999 Then num = 1。

第二类是动作顺序没校验。比如"出售物品"接口只检查背包里有没有这个物品，不检查数量够不够，玩家传一个大数量就能凭空卖出。修法是把扣减写成带条件的 UPDATE，WHERE 数量 >= 请求数量，靠影响行数判断成功与否。

第三类是时间间隔没限制。打怪的接口没有冷却，写个循环脚本一秒请求一百次。修法是在角色表里存一个"上次动作时间"，每次请求先比对，间隔不足就直接返回。这招对网页游戏特别有效，因为它的成本几乎为零。

注意：这类漏洞不是"改完就没了"，二次开发加新功能时很容易重新引入。建议在function.asp里统一封装一个SafeInt函数和一个CheckCooldown函数，新写的地方强制调用，比靠人记规矩靠谱。

5. 让它跑得动：查询优化与输入防护的具体做法

能玩和好玩之间还隔着一层——性能和稳定。Access 的承载能力有限，写法稍微不注意，几十个人在线就开始转圈。

5.1 分页、索引与减少全表扫描

老代码最常见的问题是列表页一次性SELECT *把整张表捞出来再在 ASP 里循环截取。玩家一多，背包几百条、日志几万条，页面直接卡死。

Access 的分页写法比较别扭，可以用TOP配合子查询：

' 取第 3 页，每页 20 条（按 ID 倒序） sql = "SELECT TOP 20 * FROM 战斗日志表 WHERE ID NOT IN (" & _ "SELECT TOP 40 ID FROM 战斗日志表 ORDER BY ID DESC" & _ ") ORDER BY ID DESC"

这个写法的原理是先排除掉前两页的 40 条，再从剩下的里面取 20 条。缺点是数据量大时子查询也慢，所以分页只在必要的地方用，能用"最近 N 条"就用TOP N直接取。

索引方面，Access 在表设计视图里可以给字段设"索引：有（无重复）"。需要建索引的字段是：所有出现在 WHERE 里的外键（角色ID、账号ID）、所有用于排序的字段（时间、ID）。不要给每个字段都建，Access 的索引维护成本比想象中高，写入会变慢。

另一个立竿见影的优化是拆掉SELECT *。只取需要的字段，尤其是角色表这种字段多、单行大的表。原来一次查询传几 KB，改成只取五个字段之后可能只有几百字节，页面加载时间能砍掉一半。

5.2 拼 SQL 的老代码怎么补上注入防护

这套源码里几乎没有参数化查询，全是字符串拼接。全部重写工作量太大，我一般分两步走：

第一步，把所有来自Request的值统一过一遍过滤函数。数字型强制转型，字符串型至少做单引号转义：

Function SafeStr(s) If IsNull(s) Then SafeStr = "" : Exit Function SafeStr = Replace(Trim(s & ""), "'", "''") End Function Function SafeInt(s) If Not IsNumeric(s) Then SafeInt = 0 : Exit Function SafeInt = CLng(s) End Function

第二步，新写的、以及涉及金钱和权限的关键查询，一律改成 ADO 参数化：

Dim cmd Set cmd = Server.CreateObject("ADODB.Command") cmd.ActiveConnection = Conn cmd.CommandText = "UPDATE 角色表 SET 银两 = 银两 + ? WHERE ID = ?" cmd.Parameters.Append cmd.CreateParameter("add", 3, 1, , amount) ' 3=Integer, 1=Input cmd.Parameters.Append cmd.CreateParameter("rid", 3, 1, , roleId) cmd.Execute

参数化之后，即使参数里带了引号或者分号，也只会被当成数据，不会变成语句。这一步是根治，值得花时间。

需要提醒的是：只做Replace(s, "'", "''")是不够的。老版本 Access 支持的某些函数（比如Chr）可以绕过简单的引号过滤。所以字符串型输入除了转义，还要限制长度和字符范围，双保险。

5.3 上传、输出与文件权限

游戏里难免有头像上传、公告富文本之类的功能。这三处的处理原则是：

上传——白名单扩展名（只允许 jpg/png/gif），上传后重命名成时间戳加随机串，存到专门目录，并且给这个目录配一个"禁止脚本执行"的请求筛选规则。不要只看Content-Type，那个客户端能随便改。

输出——所有玩家可编辑的内容（昵称、签名、公会名）在页面上输出时一律Server.HTMLEncode。不然一个昵称里写一段脚本，就能偷走所有看到它的人的 Cookie。这个问题在这类老游戏里特别常见，因为昵称会出现在排行榜、聊天、战斗日志等多个页面上，只要漏一处就全线失守。

文件权限——数据库目录的"目录浏览"要关掉，.mdb后缀在请求筛选中禁掉。这两条配好，就算有人猜到了路径也拿不到文件。

6. 排错实录：几个把时间吃掉的小问题

最后写几个具体现场，都是这类源码上反复出现、但搜不到现成答案的。

6.1 中文乱码到底出在哪一层

乱码有三种完全不同的成因，得先分清是哪一种：

如果只有数据库里读出来的中文是乱码，那是编码不一致。Access 存的是 Unicode，ASP 输出默认是Response.CodePage = 936，也就是 GB2312。检查页面顶部有没有<%@ Language=VBScript CodePage=936 %>和Session.CodePage = 936，两者缺一不可。

如果表单提交上去的中文变问号，那是提交编码的问题。Request.Form在读取之前要先设置Session.CodePage，顺序错了就取不到正确值。

如果只有包含文件里的中文乱码，那是文件本身编码不对。用编辑器确认那几个.asp文件是 ANSI（GB2312）保存的，别混着 UTF-8。

我遇到过一次最绕的：某个页面的中文只在火狐浏览器里乱码，其他都正常。最后发现是页面声明的 meta charset 写的是 utf-8，而实际输出是 GB2312，浏览器按声明解析就错了。把 meta 改成 gb2312 之后立刻正常。这类问题没有捷径，就是逐层对比实际字节。

6.2 时间总是差八小时

这个现象很典型：数据库里存的时间是对的，页面显示出来差八小时。原因是两处时间来源不同——数据库里的默认值Now()用的是 Access 所在机器的本地时间，而 ASP 里算的时间用的是 Web 服务器进程的时区。如果两台机器（或者容器和宿主机）时区设置不一致，就差了。

处理原则是统一到一处。要么所有时间都由 ASP 生成再写进数据库，要么都给数据库字段设成由代码显式赋值。不要依赖 Access 的默认值，那个最不好排查。

顺带说一个相关的：DateDiff计算冷却时间时，如果传入的两个时间分别来自不同时区，算出来的间隔会离谱。冷却判断最好直接用数据库里的时间戳数值（比如存一个DateDiff("s", "1970-01-01", Now())得到的秒数），比较大小，不涉及时区。

6.3 战斗结果和页面显示对不上

有一版源码里，战斗结算完成之后又用了一次Response.Redirect跳回地图页，结果玩家看到的是"战斗胜利"的提示，但角色血量还是旧的。原因是跳转之前数据没提交，或者提交了但页面读取的是 Session 里的缓存值。

在 ASP 里，Response.Redirect之前如果已经有输出，会报"HTTP 头已发送"，有些老代码为了绕过这个，把Response.Buffer关掉了，然后输出一点点内容再跳。这种做法会让后续所有Redirect都不可靠。

正确的顺序永远是：先做完所有数据库写入，再Response.Redirect，并且确保Response.Buffer = True（IIS 默认就是 True）。如果一定要给用户看提示，用Response.Write输出一段自动跳转的 HTML，别用服务端跳转。

我自己在这套东西上折腾了大半个月，最大的体会是：这类老源码看起来到处都是问题，但真正致命的地方就那么几处——数据类型一致性、随机数播种、并发写入的窗口、以及服务端对输入的信任。把这四处守住，剩下的都是体力活。改的时候一定先备份数据库文件，Access 这个格式经不起反复折腾，一个字段类型改错，可能整张表的数据就没了。