企业官网建设流程全解析

去年年底，我把XiuXianGame这个文字修仙小项目翻出来重构了一版。游戏本体不复杂，一个Flask服务，一个SQLite数据库，前端就是网页，里头的核心玩法是修炼、突破、打秘境、炼法宝。麻烦的是，游戏跑在笔记本上，自己玩没问题，想给外地朋友试玩就抓瞎。同学聚会时别人让我演示，我只能把笔记本屏幕转过去；群里有人说想玩，我就得先教他装Python、拉代码、跑服务——大部分人听到这已经跑了。

后来我决定用cpolar内网穿透解决"别人玩不到"的问题。当时正好看到cpolar内网穿透实验室的系列挑战，做到第745个成功挑战的时候，我对这个思路基本没怀疑了：本地起服务、建立隧道、生成公网链接，这套流程已经被几百次实践验证过。我给自己定的目标是两件事：第一，让文字修仙游戏不只停留在"能跑"，而是真的好玩到朋友愿意点开第二次；第二，打通cpolar隧道，让朋友们拿一个链接就能开始修仙。这篇就把这两件事的完整过程写下来。

1. 玩法是第一位的：文字修仙的"好玩"具体落在哪

1.1 境界递进不能只改数字，要改"玩法手感"

XiuXianGame最初版本很原始：点一下修炼，修为+10，修为攒够，突破按钮亮一下，然后下一个境界继续点。朋友试玩三分钟就得出结论：这是个会说话的计数器。

我把修仙的成长路径拆成几个阶段，每个阶段玩起来的手感完全不同：

炼气期最重要的设计是"高频小回报"。我加了一个任务板，每过5分钟刷新一批宗门委托，委托做完直接发灵石，灵石又能买丹方，形成一个五分钟级的循环。到了筑基期，才开始让玩家做减法：剑修攻击高但学不了治疗丹方，丹修后期资源多但前期打怪吃力。这个阶段如果还像炼气期一样什么都给，玩家反而会失去目标。

金丹期是玩家流失最严重的地方，因为失败代价开始变高。我做了个折中：炼丹失败时材料保留一半，而不是全扣光。数值设计上，失败惩罚的力度要刚好让人觉得肉疼、又不至于想删档。

1.2 随机事件：让每个人的仙途都不一样

文字游戏没有画面优势，玩法差异大多来自"剧情和事件的组合"。我给XiuXianGame写了一个事件引擎，核心就是一张加权随机表加一系列状态条件。

事件分四类：

• 奇遇类（秘府开启、前辈遗府、天材地宝出世）：中奖感强，玩家愿意主动探索
• 危险类（魔修劫道、心魔入侵）：打断日常节奏，提供紧张感
• 资源类（灵脉枯竭、药田丰收）：服务养成线
• 角色类（同门求助、散修挑战）：推动叙事

实际运行里，同一个事件在不同境界触发，处理方式完全不同。炼气期遇到魔修劫道，选项是"硬拼"或"逃"，成功率直接决定生死；元婴期再遇到魔修，就是秒杀，但会奖励声望。这个设计让玩家跑二周目时也有新鲜感。

事件触发我写了一个简单的时间+状态检查器：

def maybe_trigger_event(player): if random.random() < 0.18 and player.is_free: pool = event_pool_for(player.realm) event = weighted_choice(pool) player.current_event = event.id

0.18这个概率是调出来的，太低玩家觉得无聊，太高又会被事件打断主线操作。这个数值每位开发者手感不一样，建议做成后台配置项，方便随时调。

1.3 数值反馈：清晰比复杂更留人

还有一条很重要：游戏里所有数值改变都要说人话。突破失败不显示"突破失败"，而是写一段渡劫失败的描述，然后给出具体提升路径——"修为不足，距离下一次突破还差320年修为，建议前往天机峰闭关"。

我做数值时定了三条原则：

• 任何操作都必须有可见回报，哪怕只是+1点熟练度
• 成功率、消耗、收益要在操作前展示清楚，不能暗改
• 关键节点必须有过场式的文字演出

比如渡劫界面，玩家点击突破后不是直接判定，而是先输出多行文本模拟天雷、灵气、肉身的变化，最后才显示成功或失败。虽然只是几行文字，但从测试反馈来看，大家对"仪式感"这个点的认可度出奇地高。

2. 从单机到可访问：我拿 cpolar 对比了市面上几类内网穿透方案

2.1 单机游戏最尴尬的一刻

XiuXianGame功能做得差不多了，我开始头疼分发问题。云服务器不是不行，但为了一个展示项目，每月租一台服务器总感觉重；把代码发给朋友，对方要装Python、装依赖、跑服务、开端口，操作链太长，基本劝退普通人。视频通话里远程操控我的电脑，体验又差到没法评价。

内网穿透等于把"本地服务"临时挂到公网的一个地址上。cpolar在本地起一个客户端，把本机某个端口映射到云端，对外生成一个HTTPS链接，别人打开链接，实际访问的是我笔记本上跑着的游戏。整个过程不需要买服务器，不需要自己维护公网转发，这是它最打动我的地方。

2.2 主流内网穿透工具怎么选

"内网穿透"这个话题下能选的工具不少，我实际看了几个，也测过其中两三个，给你一个表：

这里有个容易混淆的点：frp、tailscale这类工具更偏"自建组网"，你得有自己的服务器或者每台设备都装客户端才能玩得转；cpolar、ngrok这类是"即开即用"的穿透服务，官方把公网出口准备好，客户端一跑就有地址。对我想快速让朋友试玩文字修仙这个需求，即开即用明显更顺手。

2.3 "实验室第745个成功挑战"到底在挑战什么

cpolar内网穿透实验室的系列挑战，我理解是一个持续积累的实践清单：每一次挑战都要求把一个本地服务真实地穿透出去、验证可以公网访问，然后记录过程。第745个说明这套链路已经被跑通了几百次，涉及的服务五花八门，依然能保持稳定，说明方法本身是经得起反复使用的。

我做这次挑战时，特别在意的一点是：不把挑战当成"跑一条命令截个图"就完事，而是把真实开发环境里的坑也记录下来。这样后面的读者复现时才不会被卡在文档没写的地方。这也是我在第4节写那么多踩坑内容的原因。

3. cpolar安装与隧道配置全过程：照着做就能跑通

3.1 cpolar安装：Linux和Windows各给一条路径

cpolar安装其实非常简单，官方文档写得很清楚，我在这里只补充最关键的几条命令。

Linux环境下：

curl -L https://www.cpolar.cn/static/downloads/releases/3.3.15/cpolar-stable-linux-amd64.zip -o cpolar.zip unzip cpolar.zip sudo mv cpolar /usr/local/bin/cpolar cpolar version

Windows就下载官方客户端exe，解压后放到一个固定目录，比如D:\cpolar，然后把该目录加入环境变量Path，之后在命令行里直接敲cpolar version验证。macOS也可以用brew装，不过我没有在mac上实机验证，就不写具体命令了，官网有对应安装包。

安装完第一件事是注册账号拿authtoken。去cpolar官网注册登录，后台控制台能看见自己的token，然后执行：

cpolar authtoken xxxxxx

这个token的作用是把本机客户端和你的账号绑定，不绑定的话，匿名模式通常无法使用完整功能。绑定之后生成隧道才能看到流量统计、连接详情这些信息。

3.2 让游戏服务稳定地占用一个固定端口

在建立隧道之前，先确保游戏服务跑在固定的端口上。XiuXianGame用Flask，启动代码长这样：

from flask import Flask, render_template app = Flask(__name__) @app.route("/") def index(): return render_template("index.html") if __name__ == "__main__": app.run(host="0.0.0.0", port=8000)

有两点要特别说明。第一，端口固定是8000，不要今天用8000明天用8001，隧道配置是针对端口的，服务端口一变，隧道就得跟着变。第二，host参数一定要写0.0.0.0，如果只绑定127.0.0.1，本机能访问，但cpolar客户端在转发请求时会出现访问不通的情况，实测表现就是"隧道在线但链接打不开"。这个坑我后面会详说。

3.3 创建HTTP隧道，拿到公网链接

游戏服务跑起来之后，另开一个终端窗口：

cpolar http 8000

执行后会生成一个公网地址，类似https://xxxxxxxx.cpolar.cn。把地址贴到浏览器里，如果能看到游戏首页，说明穿透链路已经通了。

此时会出现一个实时面板，本质上是一个在终端里交互的界面，按方向键可以查看请求日志、流量等信息。对文字游戏这种轻量应用来说，观察请求日志特别方便——谁在什么时间打开了链接，接口有没有报错，一目了然。

提示：免费版的随机域名在每次重启cpolar后可能会变化。如果只是临时演示，问题不大；如果想长期给朋友玩，建议直接看下面的固定域名配置。

3.4 固定域名与后台运行的进阶配置

为了让朋友不用每次找我要新链接，我申请了一个预留域名。具体方法是在cpolar后台找到"预留域名"入口，按提示创建一个专属子域，然后把它写进cpolar配置文件~/.cpolar/cpolar.yml：

tunnels: xiuxian: proto: http addr: 8000 domain: xiuxian-self.cpolar.cn

之后启动隧道的方式就变成：

cpolar start xiuxian

这样每次启动都会绑定同一个域名，链接不再漂移。如果游戏服务需要长期在后台跑，我习惯用Linux的nohup方式放后台：

nohup python game.py > game.log 2>&1 & nohup cpolar start xiuxian > tunnel.log 2>&1 &

最后说下TCP隧道。如果游戏客户端不是走HTTP协议，比如我后来接过的桌面版联机入口，需要用：

cpolar tcp 8001

它会分配一个公网的IP加端口，走的是TCP层面的映射，适合非网页类服务。

4. 把游戏暴露到公网后，我遇到的那些实际坑

4.1 服务能启动、隧道也显示在线，朋友打不开

这是最经典的"看起来一切正常但访问失败"问题。排查链路我建议按顺序来：

第一步，本机自证。先确认服务本身没挂：

curl -I http://127.0.0.1:8000

如果这条命令返回正常HTTP状态码，说明服务活着。

第二步，查监听地址。运行ss -lntp | grep 8000，看监听地址到底是0.0.0.0:8000还是127.0.0.1:8000。如果是127.0.0.1，就回到代码里改成0.0.0.0重启服务。

第三步，查防火墙。Linux桌面发行版经常默认开着防火墙，需要放行对应端口：

sudo ufw allow 8000

Windows则检查防火墙入站规则。这一轮排查下来，绝大多数"隧道在线但无法访问"的案例都能解决。

4.2 免费随机域名导致链接失效

朋友收藏的是上周的链接，结果这周再点就是404。最直接的原因是免费随机域名重启后会变化。解决分两个层次：一是在后台预留固定域名，写进配置文件，上面已经讲过；二是在暂时没有固定域名的情况下，也要养成"发布前用当前可用地址重新生成一个短链接"的习惯，别把随机链接当永久链接发出去。

另外，如果cpolar客户端意外退出，隧道就断了。我给笔记本设置了一个开机自启任务，启动后自动拉起两行nohup命令，这样即使电脑重启，过一两分钟链接又能自动恢复。这里推荐用supervisor或者systemd管理，比手动nohup更稳。

4.3 公网扫描多，必须加访问口令

服务一旦挂到公网，很快会被各种扫描工具探测。我自己观察到的现象是：纯HTTP服务公开后半小时内就有大量可疑请求，路径探测、参数注入测试都有。文字游戏本身没有敏感数据，但我不想让每个陌生人都能玩。

我实际采用的方式是在Flask里加一个极简的访问口令入口：

from functools import wraps from flask import request ACCESS_CODE = "lianqi-2024" def require_code(f): @wraps(f) def wrapper(*args, **kwargs): code = request.args.get("code") if code != ACCESS_CODE: return "欢迎来到洞府，请输入访问口令", 403 return f(*args, **kwargs) return wrapper @app.route("/") @require_code def index(): return render_template("index.html")

朋友第一次打开链接时，我会把?code=lianqi-2024附在后面，他点进去就能玩。这个方法比隧道层做认证更直观，因为我可以随时在后端换口令，不需要重新配置隧道。如果你不想改代码，也可以在cpolar隧道配置里挂HTTP基础认证，效果类似。

4.4 SQLite存档路径错误，差点弄丢存档

这是这次挑战里最难发现的坑。一开始我在代码里直接写sqlite3.connect("game.db")，在电脑上跑得好好的。把服务放到后台用nohup启动后，工作目录变成了启动命令的目录，同一个路径又生成了一份新的game.db，玩家的新存档写进了新文件，之前的存档却不被读取。结果就是朋友玩了一会说"数据怎么没了"。

解决方法很简单，用代码所在的绝对路径：

import os BASE_DIR = os.path.dirname(os.path.abspath(__file__)) DB_PATH = os.path.join(BASE_DIR, "game.db")

我还加了个每小时备份的小脚本，把game.db复制到backup目录并带时间戳。公网环境玩家会产生真实存档，数据丢一次，信任就丢了，这方面要谨慎。

5. 分享链接发出去之后：反馈、数据与下一版计划

5.1 "点击即玩"的门槛越低越好

隧道打通后，我给朋友发的东西包括一条链接和一个口令。进一步优化是两个细节：一是确认手机浏览器能正常打开，文字修仙游戏在手机上玩很合适，但按钮区域不能太小，我在CSS里给按钮做了至少44px的点击区域；二是缩短链接，如果默认分配的域名太长，可以用短链接服务包装一下，减少手动输入的出错率。

实测下来，大部分朋友在手机上打开就能直接玩，真正需要教"怎么安装Python"的情况一次都没有出现。这个对比让我很确定：内网穿透不是替代正式部署的东西，但在作品传播早期，它绝对是性价比最高的方案。

5.2 用数据看玩家卡在哪，而不是凭空猜

链接发出后的几天，我一直在看cpolar的请求日志，但日志只告诉我"谁访问了"，没有告诉我"玩到哪弃坑了"。于是我在游戏里加了一张事件日志表，把关键行为都记录下来：

INSERT INTO event_log (player_id, action, detail, created_at) VALUES (?, ?, ?, datetime('now'));

比如"完成炼气期突破""在丹炉处停留超过10分钟""秘境战斗失败3次"这类事件。之后用一条SQL就能看出问题集中点：

SELECT action, COUNT(*) FROM event_log GROUP BY action ORDER BY COUNT(*) DESC;

从数据里我发现，流失最严重的节点是筑基初期的"选主修方向"页面——选项说明写得太技术化，玩家看不懂选下去会怎样。后来我把每个方向加了一个故事化的描述和一个示例能力。改动不大，但留存明显改善。这比我自己闷头猜需求有效得多。

5.3 下一步：从单机展示走向轻联机

能够稳定分享之后，我开始琢磨增强"大家在同一个修仙世界里"的感觉。文字游戏做成完全实时联机成本高，但轻联机不需要那么复杂。最简单的一步是做一张公屏消息表，把玩家"突破金丹""炼制出上品法器"这类高光时刻插入公共频道，其他人刷新页面就能看到。

更进一步就是WebSocket实时推送。cpolar的HTTP隧道对WebSocket是支持的，不需要额外开放TCP端口。不过文字游戏的操作节奏没那么快，实时推送优先级可以往后放，把公共消息和排行榜先做出来，联机氛围就起来了。按这个节奏，XiuXianGame已经从"我一个人的小项目"变成了"一个小群共同修仙的服务器"。

5.4 一点个人体会

最后说下我自己的感受。cpolar这类穿透工具解决的是"让别人马上玩到"的问题，但它替代不了游戏本身的设计工作量。第745个挑战真正让我想明白的，是"先把游戏打磨到值得分享，再考虑怎么分享"。隧道五分钟就能通，但事件表怎么写、概率怎么调、反馈文案有没有画面感，这些功夫只能一步一个脚印地做。如果你也在做类似的小项目，别纠结技术选型，先把链接发出去，拉三个朋友试玩一晚上，得到的反馈比闷头开发一个月都值。