ASP武侠页游源码部署、核心逻辑拆解与安全优化实战

1. 先搞清楚这套ASP武侠页面游戏到底是什么

拿到一套ASP网页游戏源码，最怕的不是不会部署，而是没搞明白它的运行模型就动手改。这套以“新华山论剑”为代号的武侠题材页面游戏，本质是一个典型的 B/S 架构、页面驱动的回合制文字游戏：玩家在浏览器里点“练功”“切磋”“闯荡”，服务器上的 ASP 脚本接收请求、读写 Access 数据库、拼出 HTML 返回给浏览器。没有实时通信，没有长连接，所谓的“江湖在运转”，靠的是每次页面请求时顺带做一次状态推进。理解这一点，后面所有的部署、调试、改造才有落脚点。我见过不少人一上手就想给它加 WebSocket、换 MySQL，结果改到一半发现会话、事务、缓存全耦合在页面里，最后只能推倒重来。所以这篇内容适合三类人：手里已经有这套 ASP网页游戏源码、想把它跑起来看看效果的；想通过一个完整项目搞懂经典 ASP 项目结构的；以及打算在它基础上做二次开发、加玩法、做私服式运营的技术爱好者。哪怕你只会一点 HTML，跟着步骤也能跑通；如果你有后端经验，重点看核心逻辑和避坑部分。

1.1 技术栈与运行机理：为什么是经典ASP而不是别的

这套源码的技术选型非常有年代感：服务端用 VBScript 写的 ASP（Active Server Pages），数据库用 Access 的.mdb文件，前端是表格布局加少量 JavaScript 校验，图片资源放在images/目录下按门派、装备分文件夹堆放。它不需要编译，改完文件刷新页面就生效；不需要单独装数据库服务，一个文件就是整个库；也不需要配置复杂的路由，一个.asp文件对应一个功能页。这种“零构建”的特性，恰恰是它能被大量传播、被无数人拿来改的原因——你把文件夹丢到任何一台装了 IIS 的 Windows 机器上，配个站点就能跑。

但选型背后的代价也很明显。Access 是文件型数据库，同一时刻只允许有限的并发写入，写操作会生成.ldb锁文件，一旦有页面崩溃或者进程被强杀，锁文件残留就会导致整站“数据库被占用”；VBScript 没有真正的类型系统和异常机制，On Error Resume Next一加，错误就被吞得干干净净，排查时只能靠日志和断点式Response.Write；页面驱动意味着没有后台常驻进程，所有“定时”逻辑都得寄生在用户请求上。我个人的判断是：这套东西适合做学习样本、做小规模内网演示、做怀旧向的小圈子运营，不适合承载高并发。认清边界，比盲目优化重要得多。

还有一个容易被忽略的点：它的“页面即接口”。现代项目里，前端调/api/fight，后端返回 JSON；而这套源码里，玩家点“出招”，浏览器直接 POST 到fight.asp，服务端算完直接Response.Write出战斗过程的中文描述，中间还夹杂着<br>和<font color=red>。这意味着你做任何自动化、任何接口化改造，都得先把“渲染”和“计算”这两件事从同一个文件里拆开，这是二次开发的第一道坎。

1.2 玩法骨架与数据流向：一次点击到底经历了什么

把这套源码的功能页按数据流排一遍，脉络就清楚了。入口是index.asp（有的版本叫default.asp），负责渲染登录框和江湖公告；登录走chklogin.asp或login.asp，校验账号密码后把用户 ID、昵称、门派写进 Session；登录成功跳main.asp，这是游戏主界面，左侧是功能菜单，右侧是 iframe 或直接嵌入的角色状态面板；status.asp展示气血、内力、等级、经验；fight.asp处理切磋和打怪；bag.asp管背包；shop.asp管商店；guild.asp管帮派；rank.asp出排行榜。管理后台通常在admin/子目录下，用另一套登录逻辑。

一次完整的“切磋”请求是这样走的：浏览器 POST 带上对手 ID，fight.asp从 Session 取出自己的角色 ID，从数据库读双方属性，进入循环计算回合，每回合按攻防公式和随机系数算伤害，直到一方气血归零，把战斗过程拼成字符串，最后一次性写回数据库的血量、经验、胜负场次，再输出到页面。这里有个关键细节：很多老版本是先输出战斗文字、再写数据库，如果中途用户关掉浏览器或网络中断，战斗结果就没落库，出现“赢了但没加经验”的现象。判断方法很简单，看代码里Response.Write和Conn.Execute的先后顺序。正确的做法是先算完、先落库、再输出。

再往下看，角色的“体力恢复”“打坐回气”“NPC 刷新”这类需求，源码里普遍用请求驱动的伪定时器实现：在公共头部文件（通常叫conn.asp、top.asp或global.asp）里塞一段逻辑，每次任意页面被访问时检查一个时间戳字段，如果距上次刷新超过 N 秒，就执行一次状态推进并更新时间戳。这种设计的巧妙之处在于零成本，缺点在于“没人访问就不推进”，而且并发访问时可能重复执行。后面第 4 章会专门讲怎么用Application.Lock把它改稳。

2. 部署环境：IIS 加 Access 的最小可用组合

部署这套东西，最省事的组合就是 Windows 自带的 IIS 加一个 Access 数据库文件，不需要额外装任何运行时。但“省事”不等于“顺利”，我统计过自己踩过的坑，八成都集中在三处：ASP 功能没启用、32 位驱动没开、目录权限没给够。这三件事任何一件没做对，你看到的都是同一个结果——白屏或者 HTTP 500，而且错误信息被 IIS 默认藏起来了，让人抓瞎。所以这一章我按安装顺序讲，每一步都告诉你为什么要这么做。

2.1 环境清单与安装顺序

先列清单，避免装到一半发现缺东西。系统层面，Windows 10/11 专业版或 Windows Server 系列都可以，家庭版没有 IIS 管理控制台，会比较麻烦，建议直接换系统或者在虚拟机里做。组件层面需要：IIS 主体、ASP 模块、ISAPI 扩展或 CGI（部分老源码用它做伪静态）、URL 重写模块（可选，用于美化链接）。数据库层面，.mdb格式对应 Jet 引擎，Windows 自带；.accdb格式对应 ACE 引擎，需要单独装 Access Database Engine，而且必须装和应用程序池位数一致的那一版，这一点后面细说。

安装顺序我建议这样：先开 IIS 功能，再装数据库引擎（如果需要），最后配站点。因为 IIS 安装过程中会重置一些组件注册，先装引擎后开 IIS 有时候会被覆盖掉。

开启 IIS 的具体路径是：控制面板 → 程序和功能 → 启用或关闭 Windows 功能 → Internet 信息服务。展开后至少勾选“Web 管理工具”下的“IIS 管理控制台”，“万维网服务”下的“应用程序开发功能”里的“ASP”，以及“常见 HTTP 功能”里的“默认文档”“静态内容”“HTTP 错误”。很多人只勾了 IIS 主体就以为完事，结果访问.asp文件直接被当成下载，原因就是 ASP 模块没装。装完后在浏览器输入http://localhost，看到 IIS 欢迎页才算第一步成功。

提示：如果你在 Windows 11 上操作，功能列表里的名称可能略有差异，但“应用程序开发功能 → ASP”这一项是一定要勾的，它是整套源码能跑起来的前提。

2.2 IIS站点配置与应用程序池关键参数

站点配置这一步，新建网站时物理路径指向源码根目录，绑定端口随便给个 8080 避免和别的服务冲突，主机名留空。关键在应用程序池，这是很多人忽略的地方。默认池是 .NET CLR 的，托管管道模式是“集成”，对经典 ASP 来说不是最优。我的做法是新建一个专用池，.NET CLR 版本选“无托管代码”，托管管道模式选“经典”。选经典模式的原因是老源码里大量使用<!--#include file="..."-->和相对路径引用，集成模式下某些请求过滤规则会更严格，容易出现莫名其妙的 404.7 或 404.8。

池的高级设置里有几个必改项。第一是“启用 32 位应用程序”，如果你的 Access 是.mdb，Jet 驱动只有 32 位版本，必须把它设为 True；如果是.accdb且装的引擎是 64 位，就设为 False。这一项设错，典型症状是页面报“未找到提供程序。该程序可能未正确安装”。第二是“最大工作进程数”设为 1，因为超过 1 就进入 Web Garden 模式，Session 不共享，玩家会莫名其妙掉线。第三是“闲置超时”可以设长一点，默认 20 分钟回收一次，游戏里会有玩家挂机，回收瞬间 Session 丢失体验很差。第四是“专用内存限制”之类的保护项先别开，调试阶段容易误杀。

站点层面还要配两个东西。一是默认文档，把index.asp、default.asp加进去并排到最前，这样访问根路径就能直接进游戏。二是 ASP 的调试属性，在 IIS 管理器里点开 ASP 设置，“编译”里的“将错误发送到浏览器”设为 True，“调试属性”里的“启用详细 ASP 错误消息”也设为 True。这两项只在你本地调试时开，上线必须关掉，否则错误信息里会带出数据库路径，属于典型的信息泄露。

2.3 数据库与目录权限：最容易翻车的三处

第一处是数据库文件所在目录的权限。Access 在运行时会生成同名.ldb锁文件，也就是说它不仅需要读，还需要写和删除。默认情况下IIS_IUSRS组只有读权限，所以你一定会遇到“操作必须使用一个可更新的查询”或者“无法更新，数据库或对象为只读”。解决办法是右键数据库目录 → 属性 → 安全 → 编辑 → 添加IIS_IUSRS→ 勾选“修改”和“写入”。注意是给目录，不是只给文件，因为.ldb是在目录里新建的。

第二处是上传目录。游戏里会有头像上传、帮派徽章上传，这类目录必须给写权限，但同时必须禁止执行脚本。做法是在 IIS 里选中上传目录，双击“处理程序映射” → “编辑功能权限” → 取消勾选“脚本”和“执行”，只留“读取”。这一步不做，等于给整站开了个后门，任何人传一个.asp上去就能执行任意代码，这个风险后面第 6 章会展开。

第三处是父路径。很多源码的数据库连接写的是Server.MapPath("../data/db.mdb")这种带上级目录的相对路径，而 IIS 默认禁止父路径。表现是连接字符串解析失败，报“路径未找到”。开启方式是在 ASP 设置 → 编译 → “启用父路径”设为 True。我的建议是尽量改代码把路径写成从站点根算起的绝对相对路径，比如Server.MapPath("/data/db.mdb")，比开父路径更安全。

3. 源码落地的完整实操流程

环境准备好之后，真正的活是让这套代码认你的机器。目录结构、连接字符串、编码、初始数据，这四样对齐了，基本就能一次点亮。我按自己实际操作的顺序走一遍，中间的关键判断点会写清楚。

3.1 目录结构与文件职责梳理

拿到压缩包解压后，先别急着往站点目录扔，先在本地打开看一眼结构。典型的目录长这样：根目录下是各个功能页.asp文件，inc/或include/放公共文件（数据库连接、头部、尾部、函数库），data/或db/放.mdb，images/放美术资源，admin/放后台，upload/放用户上传，js/和css/放静态资源，有的还会有temp/或cache/放生成的静态页。

重点看inc/里的公共文件。conn.asp一般负责建连接，是全局改动的核心；function.asp或pub.asp里放通用函数，比如防注入、格式化、随机取数；top.asp和bottom.asp是页头页尾，伪定时器通常就藏在top.asp里。看懂这三类文件，整站的骨架就清楚了。

这里有个实操技巧：如果源码包里带了.sql或者说明文档，先读它，里面往往写了默认管理员账号、初始数据库路径、需要的组件版本。我遇到过好几次，说明文档里写着“数据库需放在 data 目录并命名为 game.mdb”，结果代码里写的是db/game_data.mdb，两个对不上，改代码比改文件名更稳妥。

3.2 配置文件与连接字符串改造

连接字符串是整个部署的心脏。老版本 Access 的写法是这样：

<% Dim Conn, ConnStr, DbPath DbPath = Server.MapPath("/data/game.mdb") ConnStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & DbPath & ";Persist Security Info=False" Set Conn = Server.CreateObject("ADODB.Connection") Conn.Open ConnStr %>

如果是.accdb格式，Provider 要改成Microsoft.ACE.OLEDB.12.0，并且注意位数匹配。这里有个常见误区：玩家以为是代码问题，其实是引擎没装。判断方法是写一个三行的测试页，直接Response.Write CreateObject("ADODB.Connection").Provider之类的方式试探，或者更直接地用On Error Resume Next捕获Err.Description输出到页面。报“未找到提供程序”就一定是位数或安装问题，报“找不到文件”就是路径问题，报“无法启动应用程序”多半是权限问题。

改造时我习惯做一件事：把连接字符串和站点根路径抽成常量放在文件最前面，后面所有地方引用常量。原因是这类源码经常在十几个文件里各写一份连接，改一处漏一处，跑起来时好时坏。抽出来之后，迁移服务器只需要改一个地方。

<% Const SITE_ROOT = "/" Const DB_FILE = "/data/game.mdb" Dim Conn Set Conn = Server.CreateObject("ADODB.Connection") Conn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Server.MapPath(DB_FILE) %>

3.3 首次启动自检清单与冒烟测试

配置完别急着喊人来看，先自己跑一遍冒烟测试。我整理了一套固定顺序，按这个走基本能覆盖八成问题。

测试页用完记得删掉，别留在线上。我见过有人把test.asp忘了删，里面还写着数据库绝对路径，属于把自己的家底贴在门口。

4. 核心逻辑拆解：用户、战斗、装备与定时刷新

能跑起来只是开始，真正有价值的是看懂它怎么算。这套游戏的乐趣全在数值上，数值的全在公式和概率表里。这一章我按“身份 → 战斗 → 掉落 → 心跳”的顺序拆，每一块都给出可直接对照的代码结构和参数思路。

4.1 账号与Session身份链路

Session 是这套游戏的身份证。登录成功后，代码通常会把userid、username、groupid（权限等级）写进 Session，后续每个页面开头都有一段守卫代码：读 Session，为空就Response.Redirect "index.asp"。这段守卫一般写在inc/check.asp里，被所有功能页 include。

问题在于，很多老源码只校验了 Session 有没有值，没校验这个值对应的用户在数据库里是否还存在、是否被封禁。也就是说，管理员在后台把某个号封了，只要对方不关浏览器，Session 还在，就照样能玩。修法很简单：在守卫代码里加一次数据库查询，比对用户状态字段，不通过就Session.Abandon并跳转。查询频率是每次请求一次，对 Access 来说压力不大，可以接受。

另一个坑是 Session 超时。默认 20 分钟，玩家打坐挂机回来就掉线。改法是在 IIS 里把会话超时调大，比如 120 分钟；同时在页面里加一个轻量的心跳脚本，每隔几分钟请求一次空白页，保持会话活跃。注意心跳别设太频繁，否则等于给自己制造无意义的数据库压力。

4.2 战斗结算的公式与随机数设计

战斗是这套游戏的核心。老源码的写法一般是回合制循环，双方各有一个属性组：气血（HP）、内力（MP）、攻击（ATK）、防御（DEF）、身法（AGI）、暴击率、命中率。一个回合里先比身法决定先后手，然后各自计算伤害。

伤害公式常见的形态是：

基础伤害 = ATK * ATK / (ATK + DEF) 最终伤害 = 基础伤害 * 随机系数 - DEF * 0.3

为什么用ATK*ATK/(ATK+DEF)而不是简单相减？因为减法模型在攻防差距大时会陷入两个极端：要么打不动，要么秒杀。这个除法模型的好处是伤害随攻击增长但增速递减，防御越高减伤越明显，但永远不会归零，数值曲线更平滑。我实测过，把 DEF 拉高到 ATK 的两倍，伤害仍然保留三成左右，游戏体验不会变成互相挠痒。

随机系数一般在 0.85 到 1.15 之间，写法是0.85 + Rnd() * 0.3。这里有个必须注意的点：VBScript 的Rnd()如果不先Randomize，每次页面加载都会给出同一串序列。症状很诡异——玩家发现每天早上第一场战斗结果完全一样，或者重启 IIS 后所有人的暴击全同步。修法是在公共文件里执行一次Randomize，或者用Randomize Timer让种子带时间。

暴击和闪避的判定我用的是“单次随机数比阈值”：

Dim r, isCrit, isDodge r = Rnd() isCrit = (r < critRate) ' critRate 例如 0.12 isDodge = (Rnd() < dodgeRate) ' dodgeRate 例如 0.08

注意闪避要用新的Rnd()，不能复用同一个r，否则暴击和闪避会变成互斥事件——暴击的那一下永远不可能被闪避，玩家迟早会发现这个规律。

回合上限也必须设。我建议设 30 回合，超时判血量百分比高的一方胜。不设上限的话，两个高防御低攻击的号能打到几百回合，页面卡死，数据库连接一直占着。

4.3 装备掉落与概率表

掉落是留住玩家的关键，也是最容易写出 bug 的地方。老源码常见两种写法，一种是硬编码If Rnd() < 0.05 Then给装备，另一种是查概率表。前者改起来痛苦，后者更规范。

概率表我一般设计成三列：物品 ID、权重、是否绑定。取的时候先把所有候选的权重累加，生成一个0到总权重之间的随机数，然后从头累减，减到小于等于零就命中。这个方法的好处是加物品不用改代码，加一行数据就行，而且天然保证总概率为 100%。

Function RollItem(conn) Dim rs, total, r, acc Set rs = conn.Execute("SELECT itemid, weight FROM drop_table WHERE enabled=1") total = 0 Do While Not rs.EOF total = total + rs("weight") rs.MoveNext Loop rs.MoveFirst r = Rnd() * total acc = 0 Do While Not rs.EOF acc = acc + rs("weight") If r <= acc Then RollItem = rs("itemid") Exit Function End If rs.MoveNext Loop RollItem = 0 End Function

这段代码有两个隐患要提前说。一是rs.MoveFirst在只进游标下会报错，必须用adOpenStatic或adOpenKeyset打开记录集，写法是rs.Open sql, conn, 3, 1。二是这段逻辑每次都查库，如果掉落判定频繁（比如每打一只怪判一次），Access 会被拖慢，建议把概率表在Application里缓存一份，启动时加载，改表后手动刷新。

4.4 伪定时器：页面驱动的“心跳”机制

前面提过，这套游戏没有后台进程，所有定时逻辑都靠请求触发。典型实现在top.asp里：

<% Dim lastTick, nowTick nowTick = Now() Application.Lock lastTick = Application("lastTick") If IsEmpty(lastTick) Or DateDiff("s", lastTick, nowTick) >= 60 Then Application("lastTick") = nowTick Application.Unlock ' 执行体力恢复、NPC 刷新等逻辑 Else Application.Unlock End If %>

这里Application.Lock是必须的，它保证同一时刻只有一个请求进入刷新逻辑，否则并发访问时会重复执行，玩家体力翻倍涨。但锁的范围要尽量小，只包住“判断 + 更新时间戳”，真正的业务逻辑放到解锁之后执行，避免所有请求被串行阻塞。

还有一个细节：Application变量在应用程序池回收后会清空，所以判断条件里要加IsEmpty。同时最好在数据库里也存一份时间戳，启动时从库里读回来，防止回收瞬间被当成“需要刷新”而执行一次异常跳变。我踩过一次，回收后所有玩家体力瞬间满值，被玩家当成福利刷了一波，修了半天数据。

5. 高频踩坑与排查实录

调试这套源码，最花时间的不是写代码，是猜。错误信息被吞、编码层层转换、锁文件残留，每一件都能耗掉半天。这一章我把遇到过的典型问题整理成可对照的排查表，并附上我自己的定位手法。

5.1 中文乱码的三层排查法

乱码是这类项目最高频的问题，而且原因分三层，必须逐层排除。第一层是文件本身的保存编码。ASP 页面如果存成 UTF-8 带 BOM，IIS 解析时会把 BOM 当字符输出，页面顶部出现一个看不见的乱码或者多余的空白行。解决方法是用编辑器另存为“UTF-8 无 BOM”，或者干脆存成 ANSI（GB2312）。

第二层是页面声明。ASP 文件头部的<%@LANGUAGE="VBSCRIPT" CODEPAGE="936"%>决定了服务端按什么编码解析文件，Response.CharSet = "gb2312"决定浏览器按什么编码渲染。两者必须一致，文件保存编码也必须一致。三者错一个，中文就是问号或者方块。

第三层是表单和数据库。表单提交时浏览器按页面的 CharSet 编码发送，服务端用Request.Form接收时，如果页面 CharSet 和文件 CODEPAGE 不一致，收到的就是乱码。数据库这边，Access 的文本字段本身不挑剔，但写入时的编码错了一路错到底。

我的定位手法是从最末端往回查：先在页面里写一行固定的中文，看是否正常，正常说明渲染层没问题；再看Request.Form("xx")输出是否正常，正常说明接收层没问题；最后查库里存的值，正常说明写入层没问题。三层逐一排除，比到处改配置高效得多。

5.2 Access 锁文件残留与并发写入

症状很典型：页面突然全部报“数据库已被占用”或“无法更新”，看目录里多了一个.ldb文件。原因是某个请求在写入过程中异常中断，连接没关闭，Jet 引擎留下的锁没释放。直接删.ldb有风险，如果真有进程在写，删了会造成数据损坏；正确做法是先停掉应用程序池，确认没有进程占用，再删锁文件，然后重启池。

根治的办法是规范连接的关闭。每个页面的末尾都要Conn.Close: Set Conn = Nothing，而且要保证在出错路径上也能执行到。VBScript 没有finally，我通常用一个子过程包起来，或者把关闭逻辑放在页尾的公共文件里。另一个有效手段是给写操作加短事务：

Conn.BeginTrans On Error Resume Next Conn.Execute("UPDATE users SET hp=hp-10 WHERE id=" & uid) If Err.Number <> 0 Then Conn.RollbackTrans Else Conn.CommitTrans End If On Error Goto 0

事务能保证要么全成要么全不成，但要注意 Access 的事务粒度比较粗，事务里别夹着长时间的页面输出。

5.3 五百错误的快速定位路径

看到 HTTP 500 别慌，按这个顺序走：先确认 IIS 里 ASP 的“将错误发送到浏览器”是开的；然后在web.config或者 IIS 的“错误页”里把详细错误打开；接着看 IIS 日志，路径一般在C:\inetpub\logs\LogFiles\W3SVC1\下面按日期命名的文件，里面有sc-win32-status字段，能区分是权限问题还是脚本错误。

如果错误信息指向某一行，但你看不出问题，八成是include的文件路径错了。经典 ASP 的 include 是编译期展开，路径写错时报的错误往往指向调用方，而不是被包含的文件。我的习惯是在每个 include 语句旁边注释上它应该提供的变量，出问题时先注释掉 include，看错误是否变化。

还有一种情况是“白屏无错误”。通常是On Error Resume Next在某个公共文件里加了一次就没关掉，后面所有错误都被吞了。全局搜一遍On Error Resume Next，确认每一处后面都有On Error Goto 0收尾。

5.4 上传功能失效与权限误配

上传不成功，先看三处：目录是否存在、是否有写权限、Request.BinaryRead是否被 IIS 限制。IIS 默认对请求体大小有限制，大约 30MB，超过就报错，需要在web.config里调maxAllowedContentLength。另外老源码用Request.BinaryRead(Request.TotalBytes)读整个请求体，如果TotalBytes为 0，说明表单的enctype没设成multipart/form-data。

更要紧的是安全。上传目录必须禁脚本执行，这点前面说过。我还会在上传处理代码里加一道白名单校验：只允许 jpg、png、gif，并且取扩展名时用Right(filename, 4)判断，不要相信Content-Type，那个字段是浏览器说了算，随便伪造。

6. 安全加固与性能优化

这类老源码放到公网上，基本等于裸奔。SQL 注入、上传漏洞、越权访问，随便一个都能被扫出来。但加固不需要推倒重来，抓住几个关键点就能把风险压到很低。

6.1 从字符串拼接走向参数化查询

老代码的 SQL 几乎全是拼接，"SELECT * FROM users WHERE name='" & name & "'"，只要用户在输入框里塞一个单引号加条件，就能绕过密码。最低成本的修法是写一个过滤函数，把所有单引号替换成两个单引号：

Function SafeStr(s) If IsNull(s) Then SafeStr = "" : Exit Function SafeStr = Replace(Replace(s, "'", "''"), "--", "") End Function

这招能挡住大部分低级注入，但挡不住数字型注入，因为数字字段不需要引号。真正的解法是参数化，用ADODB.Command：

Dim cmd Set cmd = Server.CreateObject("ADODB.Command") cmd.ActiveConnection = Conn cmd.CommandText = "SELECT * FROM users WHERE name=?" cmd.Parameters.Append cmd.CreateParameter("name", 202, 1, 50, userName) Set rs = cmd.Execute

202是adVarWChar，1是adParamInput。这套写法稍微啰嗦，但安全等级完全不一样。我的做法是先改登录、注册、充值这类关键页面，其余页面加过滤函数兜底，分阶段推进。

6.2 上传、包含与越权三道防线

上传防的是脚本执行，前面讲过目录禁脚本加扩展名白名单。文件包含防的是include的路径被用户控制，老源码里偶尔会出现<!--#include file="<%=page%>"-->这种写法，等于把任意文件读进来。修法是白名单映射，用户传个编号，代码里映射到固定文件名。

越权防的是改 ID。很多功能页只判断“登录了没”，不判断“这个数据是不是你的”。玩家把 URL 里的userid=5改成userid=6，就能看别人的背包、发别人的消息。修法是在每个涉及数据操作的页面，都把 Session 里的用户 ID 和参数里的 ID 做比对，不一致直接拒绝。

6.3 缓存与静态化带来的性能提升

Access 撑不起高并发，但小圈子够用，前提是把不必要的查询砍掉。最有效的三招：一是把配置类数据（门派列表、装备基础属性、地图信息）加载到Application里，启动时读一次；二是把不常变的页面生成静态 HTML，用 FSO 写到cache/目录，用户直接读静态文件；三是合并 CSS 和图片，减少请求数。

静态化的写法大致是：先在后台点“生成”，代码遍历模板和数据，拼出完整 HTML，fso.CreateTextFile写盘；前台访问时判断静态文件是否存在、是否过期，存在就直接Response.Redirect或者用Server.Transfer到静态页。注意Server.Transfer之后脚本还在执行，记得加Response.End。

7. 二次开发与长期维护的几条经验

改到这一步，你手里已经是一个能跑、能玩、还算安全的版本了。剩下的事是把代码理顺，避免下次改动又踩一遍坑。

7.1 先分层再改玩法

我建议做的第一件事是把公共文件重构一下，拆成db.asp（连接）、auth.asp（身份校验）、util.asp（工具函数）、game.asp（核心算法）、layout.asp（页头页尾）。所有页面只 include 需要的。这样做的直接好处是，你改战斗公式只需要动game.asp，不用担心某个页面漏改。

第二件事是给数据库加字段注释表。Access 没有注释功能，我通常在根目录放一个schema.txt，写清楚每张表的每个字段含义、取值范围、被哪些页面引用。这套东西在多人协作或者隔半年再回来看的时候，价值极高。

7.2 数据迁移与玩法扩展的边界

如果哪天你想把它迁到 MySQL，工作量主要在 SQL 语法差异上：Access 的Now()对应 MySQL 的NOW()，DateDiff参数顺序不同，自增字段在 Access 里是AutoNumber，在 MySQL 里是AUTO_INCREMENT，TOP 10要改成LIMIT 10。我的建议是用一层封装把常用查询包起来，迁移时只改封装层。

玩法扩展方面，这套架构能承受的复杂度有限。加新门派、新装备、新地图，都是加数据，没问题；加实时 PVP、加聊天室，就得引入长连接，那是另一个技术栈的事。我个人的经验是，与其在一个页面驱动的框架里硬塞实时功能，不如把实时部分单独做一个服务，用轮询同步数据，改造量小得多。

最后说个实操心得。这套源码里有很多“历史遗留的聪明写法”，比如用Application存全局计数器、用文件锁做并发控制、用隐藏表单字段传状态。看到这些别急着骂，先搞清楚它当时解决了什么问题，往往你会发现在那个约束下，它确实是成本最低的方案。真正该改的是那些会引发数据不一致、安全漏洞的部分，而不是所有看起来“不现代”的代码。我调这套东西前后花了大概两周，其中一半时间是在理解作者当年的取舍，理解完了，改起来反而快。