1. 从零拆解4399小游戏下载这件事1.1 为什么有人要下载swf文件而不是直接在线玩4399上的Flash小游戏本质上就是一个.swf文件被嵌在网页里播放。在线玩当然方便但有几类人会有下载需求一是想在没有网络的环境下玩比如老电脑、离线平板二是想收藏某些已经下架或者随时可能消失的经典小游戏三是做逆向分析或者学习Flash动画结构的人想拿现成的swf文件研究四是部分游戏在网页端加载慢、广告多本地播放体验更干净。我最早接触这个需求是帮一个朋友把他小时候玩的一款塔防小游戏保存下来。那游戏在4399上还能打开但谁也不知道哪天就没了。Flash Player已经在2020年底停止支持浏览器端能玩是因为4399自己做了适配方案但源文件本身还是swf格式。只要拿到这个swf用独立的Flash Player Projector就能本地运行不依赖浏览器。这里要先说清楚一个概念swf是Flash的最终产物格式它里面打包了矢量图形、位图、音频、ActionScript脚本等资源。它不是视频不是图片是一个可交互的富媒体容器。理解这一点很重要因为后面找文件、下载文件、播放文件全都围绕这个格式的特性展开。1.2 适合哪些人参考这篇内容这篇内容适合三类人第一类是完全不懂技术、只想把游戏存下来的普通玩家我会给出最省事的方案第二类是会一点Python、想用requests批量抓取的学习者我会把请求逻辑、反爬应对、429报错处理讲透第三类是习惯用迅雷等下载工具的人我会说明什么情况下迅雷能加速、什么情况下反而添乱。需要提前说明的是我下面讲的方法都是基于公开网页的正常访问行为目的是个人收藏和学习研究。批量抓取时一定要控制频率不要对目标服务器造成压力这是基本的网络礼仪也是避免自己IP被限制的关键。2. 核心思路与方案选型2.1 找到swf真实地址的三种路径下载swf核心就一件事找到这个文件的真实URL。4399的网页结构决定了swf不会直接写在地址栏里它藏在页面的某个位置。我总结下来有三条路径按难度从低到高排列。第一条路径是浏览器开发者工具。打开游戏页面按F12切到Network面板筛选swf类型然后刷新页面或者点击开始游戏。这时候你会看到一条以.swf结尾的请求右键复制链接就是真实地址。这个方法最直观适合所有人缺点是有些游戏把swf藏在iframe或者动态加载的JS里Network里可能一次出现好几条需要自己判断哪条是主文件。第二条路径是查看网页源代码。在游戏页面右键查看源代码搜索.swf通常能在embed、object或者某段JS变量里找到。4399早期页面大量使用embed srcxxx.swf这种写法一眼就能看到。现在很多页面改成了JS动态拼接源码里可能只有一个变量名需要顺着找。第三条路径是分析游戏加载接口。有些游戏不是直接加载swf而是先请求一个接口返回游戏配置配置里包含swf地址。这种情况就要看XHR请求找到返回JSON的那个接口里面往往有game_url或者swf_url字段。这条路径适合会看网络请求的人。2.2 为什么requests是批量下载的首选单个下载用浏览器就够了但如果想批量保存几十个游戏手动一个个复制链接太累。这时候Python的requests库就是最顺手的工具。选它有几个理由语法简单几行代码就能发请求能自定义请求头模拟浏览器访问能处理cookies和session应对需要登录或者有会话校验的站点配合os和time模块可以控制下载节奏。对比一下其他方案用urllib也行但写起来啰嗦用selenium能拿到动态渲染后的地址但重、慢杀鸡用牛刀用scrapy适合大规模爬取但对几十个游戏来说过度设计。requests刚好卡在中间轻量又够用。不过requests有个坑要注意它默认不会执行JS。如果swf地址是JS动态生成的requests拿到的HTML里可能没有真实地址。这时候要么先分析出JS的拼接规律要么退回到用浏览器工具手动找。我后面会讲怎么判断属于哪种情况。2.3 迅雷在这件事里到底有没有用热搜词里出现了迅雷我猜很多人是想用迅雷下载swf。实测下来迅雷对swf的加速效果非常有限。原因很简单swf文件通常只有几百KB到几MB服务器带宽也够单线程下载几秒钟就完事了。迅雷的加速依赖多源和P2P而swf这种小众文件几乎没有其他节点做种加速无从谈起。更麻烦的是有些swf地址带防盗链校验迅雷直接粘贴链接可能返回403。这时候反而要手动补Referer头而迅雷的界面里不好设置这个。所以我的建议是单个小文件直接用浏览器另存为批量用requests脚本迅雷留给大文件。如果非要用迅雷先把swf下载到本地再用迅雷打开也行但没必要。3. 实操过程与关键环节3.1 用开发者工具定位swf地址的完整步骤我以Chrome为例把步骤拆细。打开4399的游戏页面等页面加载完按F12打开开发者工具。切到Network面板在筛选框里输入swf如果没看到请求就点一下筛选栏的Fetch/XHR旁边的All确保没有过滤掉。然后按F5刷新页面或者点击游戏开始按钮。这时候观察请求列表找以.swf结尾的那条。点进去看HeadersRequest URL就是完整地址。有时候会有多条swf比如游戏主文件、预加载资源、音效文件。判断主文件的方法看Size主文件通常最大看Initiator主文件一般由游戏容器页面直接发起看Response如果能在Preview里看到一堆二进制乱码基本就是它。复制URL的时候注意有些地址带时间戳或者token参数比如?v1234567890这种参数有时效性复制完整链接才能下载。如果只复制到.swf就截断可能返回404。提示如果Network里死活看不到swf请求试试在游戏画面上右键有些老游戏会弹出Flash的右键菜单里面可能有查看源文件之类的选项能直接定位到swf。3.2 用requests写一个可复用的下载脚本找到地址后单个下载用浏览器另存为就行。但如果你有一批地址写个脚本更省事。下面是我常用的模板你可以直接改地址列表用。import requests import os import time # 请求头模拟浏览器Referer很重要很多站点校验这个 headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Referer: https://www.4399.com/, Accept: */* } # 要下载的swf地址列表换成你自己的 swf_list [ https://example.com/game1.swf, https://example.com/game2.swf, ] save_dir swf_downloads os.makedirs(save_dir, exist_okTrue) for url in swf_list: filename url.split(/)[-1].split(?)[0] filepath os.path.join(save_dir, filename) try: resp requests.get(url, headersheaders, timeout30, streamTrue) resp.raise_for_status() with open(filepath, wb) as f: for chunk in resp.iter_content(chunk_size8192): if chunk: f.write(chunk) print(f下载成功: {filename}, 大小: {os.path.getsize(filepath)} 字节) except requests.exceptions.RequestException as e: print(f下载失败: {url}, 原因: {e}) # 控制频率避免触发429 time.sleep(2)这段代码有几个关键点。streamTrue配合iter_content是分块下载适合大文件也避免一次性把内容读进内存。Referer头必须带4399的swf很多都校验来源页不带就返回403。time.sleep(2)是主动限速后面讲429的时候会详细说为什么这个很重要。3.3 参数计算与文件校验下载完成后怎么确认文件是完整的最直接的方法是看文件头。swf文件的前三个字节是FWS未压缩或者CWSzlib压缩第四个字节是版本号。你可以用Python快速校验def check_swf(filepath): with open(filepath, rb) as f: header f.read(8) if header[:3] in (bFWS, bCWS): version header[3] file_size int.from_bytes(header[4:8], little) print(f有效swf, 版本: {version}, 声明大小: {file_size} 字节) return True else: print(不是有效的swf文件) return False如果文件头不对说明下载到的可能是错误页面比如403的HTML。这时候要回头检查Referer和URL是否正确。另外声明大小和实际文件大小可能不一致因为CWS是压缩的声明大小是解压后的大小实际文件会更小这是正常的。3.4 本地播放swf的正确姿势下载到swf后浏览器已经不能直接播放了因为Flash插件被移除了。你需要Flash Player Projector也就是独立播放器。这个工具是Adobe官方出的不依赖浏览器直接打开swf就能运行。网上能搜到各个版本的projector选一个和你系统匹配的即可。打开projector后File菜单里选Open加载swf。如果游戏需要键盘操作projector默认支持。有些游戏会检测是否在浏览器里运行如果检测不到就报错这种情况比较少见遇到了可以试试用ruffle这个开源Flash模拟器它对现代系统的兼容性更好。注意projector版本不要选太新的有些新版反而去掉了对老ActionScript 2.0的支持。我实测下来Flash Player 10到11的projector对4399老游戏兼容性最好。4. 429报错与反爬应对实录4.1 exceeded retry limit, last status: 429 too many requests 到底什么意思这个报错在热搜词里反复出现说明很多人批量下载时撞上了。429是HTTP状态码意思是请求过多。服务器检测到你在短时间内发了大量请求判定为异常流量于是拒绝服务。exceeded retry limit是requests库在重试多次后仍然失败抛出的提示last status: 429说明最后一次尝试收到的还是429。为什么会出现最常见的原因就是没有控制请求频率。比如你写了个循环一口气请求100个swf每个间隔0.1秒服务器瞬间收到大量请求直接触发限流。另一个原因是没有带正确的请求头服务器把你看成爬虫直接限流。还有一种情况是共享IP比如你在某个网络环境下出口IP被其他人用滥了你跟着遭殃。4.2 从代码层面解决429的四个手段第一个手段是加延时。这是最简单也最有效的。把time.sleep的值调大比如每个请求间隔3到5秒。如果目标站点限流严格间隔10秒也不过分。宁可慢不要被封。第二个手段是加请求头。完整的请求头包括User-Agent、Referer、Accept、Accept-Language、Connection等。有些站点还会检查Sec-Fetch-*系列头。你可以直接从浏览器开发者工具里复制一条真实请求的Headers全部带上。第三个手段是用session保持会话。requests的Session对象会自动处理cookies让服务器认为你是同一个用户在连续访问而不是一堆独立请求。代码上把requests.get换成session.get即可。session requests.Session() session.headers.update(headers) resp session.get(url, timeout30)第四个手段是处理重试逻辑。不要用死循环重试要用指数退避。第一次失败等2秒第二次等4秒第三次等8秒最多重试3次。requests有Retry和HTTPAdapter可以配置from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry retry_strategy Retry( total3, backoff_factor2, status_forcelist[429, 500, 502, 503, 504], ) adapter HTTPAdapter(max_retriesretry_strategy) session.mount(https://, adapter) session.mount(http://, adapter)backoff_factor2意味着重试间隔按2的幂增长第一次2秒第二次4秒第三次8秒。这样既给了服务器喘息时间也提高了最终成功率。4.3 常见问题速查表问题现象可能原因解决方法下载到HTML而不是swfURL错误或需要Referer检查URL是否以.swf结尾补上Referer头403 Forbidden防盗链校验补Referer、User-Agent用session429 Too Many Requests请求频率过高加延时、用指数退避、降低并发文件能下载但打不开文件不完整或非swf校验文件头FWS/CWS重新下载Network里找不到swf动态加载或iframe嵌套查看XHR请求或分析JS拼接逻辑projector打不开游戏版本不兼容换Flash Player 10/11或用ruffle4.4 我踩过的几个坑第一个坑是Referer写错。我一开始只写了https://www.4399.com没带末尾斜杠结果部分游戏返回403。后来发现有些游戏的校验逻辑是精确匹配来源页必须写完整的游戏页面地址。所以最保险的做法是Referer直接填你打开游戏的那个页面URL。第二个坑是文件名冲突。很多swf的URL最后都是game.swf或者main.swf批量下载时会互相覆盖。解决办法是用URL的路径部分做文件名或者用游戏ID命名。我在脚本里加了url.split(/)[-1]但如果多个URL最后一段相同还是会冲突。更稳妥的是用hashlib.md5(url.encode()).hexdigest()生成唯一文件名。第三个坑是下载到0字节文件。有时候请求返回200但内容为空。这通常是服务器返回了空响应或者被中间层拦截了。我在脚本里加了大小检查如果文件小于1KB就报警提醒自己手动复查。5. 批量抓取与进阶技巧5.1 从游戏列表页批量提取swf地址如果你想下载一个系列的游戏手动一个个找地址太慢。可以写个脚本先从列表页提取所有游戏详情页的链接再逐个访问详情页找swf。这里的关键是列表页的HTML结构要稳定4399的列表页通常有固定的class名用BeautifulSoup或者lxml解析即可。from bs4 import BeautifulSoup list_url https://www.4399.com/flash/xxx.htm resp requests.get(list_url, headersheaders) soup BeautifulSoup(resp.text, lxml) # 假设游戏链接在class为game-list的div里 links [a[href] for a in soup.select(.game-list a)]拿到详情页链接后再逐个请求从详情页里找swf地址。这一步可以用正则匹配.swf也可以找embed标签的src属性。注意控制频率列表页和详情页之间也要加延时。5.2 用正则从JS里抠出swf地址有些页面把swf地址藏在JS变量里比如var gameUrl https://xxx/game.swf;。这时候用正则最方便import re pattern re.compile(r[\](https?://[^\]\.swf[^\]*)[\]) matches pattern.findall(resp.text)这个正则能匹配http或https开头、以.swf结尾可能带参数的字符串。如果匹配不到说明地址是拼接出来的比如https:// domain / gameId .swf这种情况就要分析拼接逻辑手动构造。5.3 多线程下载的取舍单线程下载慢但安全。多线程下载快但容易触发429。我的建议是如果目标站点限流严格老老实实单线程加延时如果站点没限流可以用ThreadPoolExecutor开3到5个线程。不要开几十个线程那是在给自己找麻烦。from concurrent.futures import ThreadPoolExecutor with ThreadPoolExecutor(max_workers3) as executor: executor.map(download_one, swf_list)max_workers3意味着同时最多3个请求。配合每个请求内部的延时整体速度比单线程快又不会太激进。5.4 下载后的整理与归档下载了一堆swf后建议按游戏名或者分类建文件夹把swf和对应的截图、说明放在一起。如果swf有配套的资源文件比如外部加载的图片、音频也要一并保存否则游戏可能运行不完整。判断方法用projector打开swf如果画面缺图或者没声音说明有外部资源没下载。有些swf会通过Loader.load()加载同目录下的其他文件这时候你需要在Network面板里观察所有请求把相关的资源都下载下来并保持相对路径不变。这个工作量比较大适合对某个游戏特别有爱的情况。6. 关于Flash的几点个人体会Flash虽然已经退出历史舞台但4399上沉淀的大量小游戏是一代人的记忆。我自己的做法是把特别有感情的几个游戏下载下来用projector在本地跑偶尔打开玩两把。这个过程里找地址、处理429、校验文件每一步都踩过坑但搞定之后的满足感很实在。如果你只是想存一两个游戏浏览器开发者工具加另存为就够了不用折腾脚本。如果你要批量保存requests加延时加session是标配429不可怕放慢速度就能解决。迅雷在这件事上帮不上大忙别在这上面浪费时间。最后提醒一句下载归下载别拿去商用也别高频请求给服务器添堵这是玩这个的基本分寸。