用爬虫追踪Steam硬件调查：Mac玩家与Apple Silicon趋势

1. 先把问题问对：什么叫"Mac玩家变多"

"Steam上的Mac玩家越来越多"这句话，我在群里、论坛里、评论区里都见过无数次，但每次看到我都会先反问一句：你说的是哪个数字？是 Steam 硬件调查里 macOS 那一行的百分比，还是你自己身边用 Mac 打游戏的朋友数量，还是某个游戏 Mac 版销量占比？这三件事经常给出完全相反的答案。我自己是长期用 Mac 打 Steam 的人，从 Intel 时代的 MacBook Pro 一路换到 Apple Silicon，中间因为好奇"到底是我自己变多了，还是大家都变多了"，动手把 Steam 硬件调查的历史数据爬下来攒了一年多。这篇就把我攒数据的方法、踩过的坑、以及我对这个问题的真实判断，全部摊开讲。适合两类人看：一类是想搞清楚这个趋势真相的普通玩家，另一类是手上有 Mac、想自己搞点数据折腾的开发者——后面有完整可复现的爬虫代码。

1.1 三个口径，三套结论

很多人争论半天其实是在鸡同鸭讲，因为"Mac玩家变多"至少有三种完全不同的衡量方式，而它们在数据上经常打架。

• 占比口径：macOS 在 Steam 全体样本里的百分比。这个数字天生吃亏，因为它是个"分母被 Windows 撑到极大"的比例，分母里全是廉价游戏本和网吧机器，Mac 永远显得很小。
• 绝对值口径：用占比去乘 Steam 的月活总量，换算成人数。这个数字其实是在涨的，因为 Steam 整体盘子这几年也在扩张，哪怕占比原地不动，绝对人数也会跟着涨。
• 结构口径：Mac 这块样本内部的结构变化，比如 Intel Mac 和 Apple Silicon 的比例、独显机型和核显机型的比例。这个口径最能反映"Mac 玩家是不是变强了"，也最有意思。

我把这三个口径整理成一张对照表，你可以拿它去判断别人跟你争论时到底在说哪一层。

我的建议是：跟人讨论的时候先锁定口径，别跨着聊。你拿占比去说服一个拿体感的人，基本说服不了；反过来也一样。

1.2 为什么官方调查的百分比会骗人

Steam 硬件调查是个自愿上报的抽样调查，不是全量统计。它的样本来自"当月登录过 Steam 并且被抽中弹窗提问"的用户，这中间有几层筛选，每一层都会往某个方向偏。

第一层偏在"会不会被抽中"。样本量相对 Steam 的体量来说并不算大，当某一类设备在总样本里只占一两个百分点时，几百台的波动就能让百分比抖动零点几个点，看上去像"断崖"或"暴涨"，其实可能只是抽样的噪声。第二层偏在"谁愿意上报"。装了新机器的人更愿意点"是"，这会让新机型在调查里被高估一小段时间。第三层偏在"谁在真正打游戏"。很多人的 Mac 是工作主力机，Steam 常年只挂着不玩，这类账号如果被抽中，会把 Mac 的"游戏含量"进一步稀释。

注意：把月度百分比当成精确测量值去算增速、算复合增长率，是没有意义的。它的置信区间比很多人想象的要宽得多。看趋势至少要看 6 到 12 个月的移动平均。

这也是我为什么决定自己攒数据：不是我不信官方，而是我需要看到连续的、可以自己算平滑曲线的原始序列，而不是每个月看一眼新闻标题里那一句"macOS 占比 XX%"。

1.3 我用的数据源和取舍

我能拿到的数据源大概就这么几类，各有各的毛病，最后我是组合使用的。

我最后的做法是：以 Steam 硬件调查为唯一的事实基准，自己每月抓一次落库；第三方存档只用来做交叉验证，不作为引用来源；本地日志只用来验证自己的排查结论。这是一个比较务实的取舍——宁可序列短一点，也不要口径混杂。

2. Steam硬件调查是怎么算出来的

想看懂那几行数字，得先知道它是怎么产生的。我见过太多人拿硬件调查的截图当"铁证"，但连页面上那两列数字分别是什么都没搞清楚。

2.1 采样机制与它的先天偏差

硬件调查的原始逻辑很简单：客户端在一次会话里弹出询问，用户点确认后，客户端把当前机器的软硬件信息打包上报。它的统计颗粒度是"账号+设备"，不是"人"。一个人有多台机器、一台机器有多个账号，都会造成重复或漏计。此外，调查页面展示的百分比是按"操作系统大类"先聚合，再在类内展开细分版本的，所以你在页面上看到的 macOS 版本分布，其实是"Mac 内部"的占比，不是全员占比。

这里有个特别容易搞错的点：页面上的两列百分比含义不一样。一列是该条目在所属大类里的占比，另一列是相对上期的变化量。很多人把变化量那一列当成占比读，得出"Mac 占了 3%"这种结论。我第一次看的时候也差点读错，后来是把表格里所有百分比加起来验证了一遍才确认——大类内占比加起来应该接近 100%，对不上就是你读错列了。

2.2 从表格里认出Mac：几个坑

真要写代码去解析，你会发现 macOS 那一行不是永远叫同一个名字，这是最烦人的地方。

• 早期会写成MacOS 10.x或者OSX 10.x这样的写法，大写小写、空格位置都不稳定。
• 后来统一到macOS 13.x、macOS 14.x这种形式，但版本号出现和消失的速度很快，某个小版本可能只在一个月的快照里出现过。
• Apple Silicon 在 CPU 相关的表格里可能是Apple M1、Apple M2、Apple M3、Apple M4这种形式，也可能被归到ARM大类下面。
• 显卡表格里，Apple 的核显历史上出现过Apple M1、Apple M2直接作为"显卡型号"出现的情况，而不是传统的Intel Iris那种命名。

所以我解析时不写死任何匹配规则，而是"把所有表都抓下来，按表标题归类"，然后做一层宽松的正则过滤。这样页面改版、命名变动，最多是分类不准，不至于整段数据丢掉。

2.3 月度抖动的真实来源

我自己攒的曲线里，macOS 那条线有几个非常规律的抖动源，识别出来之后就不会被吓到了。

第一是新机发布季。新 Mac 集中出货的那两三个月，Mac 样本会明显抬升，然后慢慢回落。第二是长假和学期节点，学生群体的设备结构会整体变化，连带影响 Mac 的占比。第三是 Steam 自身的大版本更新或者大型促销，会拉进来一批平时不登录的账号，这批人里 Mac 的比例和常驻用户不一样。第四是统计口径本身的调整，官方偶尔会改分类方式，你会看到某个月的分类里突然多出来一个新条目。

提示：如果你自己做数据，建议在数据库里单独记一列crawled_at，记录抓取时刻。官方页面是滚动更新的，同一个月份的两次抓取结果可能略有不同，出了争议你能自证。

3. 动手写一个硬件调查爬虫，把趋势攒出来

这部分是给想自己动手的人看的。整套流程在 Mac 上跑通大概半小时，难点不在代码，在于你要理解"官方只留当期数据，所以你必须自己攒"这个前提。如果你不攒，永远只能看到今天这一格。

3.1 页面结构与"全表抓取"策略

硬件调查的页面上有十几张表，操作系统、CPU、内存、显卡、显存、硬盘空间、分辨率等等，每张表的结构都差不多：一行一个条目，第一格是名字，后面跟占百分比和变化量。表的位置和标题会随页面改版变动，所以我不做"精确定位某一张表"的设计，而是遍历整页所有table元素，用每个表上方最近的一个标题元素作为它的类别名。

这个策略的好处是容错。坏处是可能抓到一些无关的表，但后面用 SQL 过滤就行，成本极低。我在实际写的时候还留了一手：如果某个表找不到前置标题，就用<caption>，再找不到就记为unknown，抓完先打出来看一眼，确认没有大面积的unknown再入库。

3.2 Mac上的环境准备

Mac 上我建议用 Homebrew 装 Python，不要用系统自带的那个。系统自带的 Python 版本老、权限受限，装包经常出各种奇怪的报错，尤其是往系统目录写东西的时候。用 Homebrew 装完之后，虚拟环境干净，出问题好排查。

# 如果你还没装 Homebrew，先按官网指引装好 brew install python@3.12 # 建一个独立环境，别污染全局 mkdir -p ~/scripts/hwsurvey && cd ~/scripts/hwsurvey /opt/homebrew/bin/python3.12 -m venv .venv source .venv/bin/activate pip install requests lxml pandas matplotlib

Intel 机型的 Homebrew 前缀是/usr/local，Apple Silicon 是/opt/homebrew，两边路径不一样。这个前缀问题导致的报错能占 Mac 开发问题的三成以上，后面第 5 节我还会再提。

3.3 抓取与解析代码

下面这段是我实际在跑的核心逻辑，做了一些精简，但结构是完整的。注意请求头里我特意写成 Mac 的 UA，并且加了Accept-Language，这样拿到的页面语言更稳定，解析少踩坑。

import re import time import sqlite3 import datetime as dt import requests from lxml import html PAGES = [ "https://store.steampowered.com/hwsurvey/", "https://store.steampowered.com/hwsurvey/" "Steam-Hardware-Software-Survey-Welcome-to-Steam", ] HEADERS = { "User-Agent": ( "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/124.0 Safari/537.36" ), "Accept-Language": "zh-CN,zh;q=0.9,en;q=0.8", } PCT = re.compile(r"(-?\d+(?:\.\d+)?)\s*%") def table_title(table): """往上找最近的标题元素，找不到就退化为 caption""" heads = table.xpath( "preceding::*[self::h1 or self::h2 or self::h3 or self::h4]" "[1]//text()" ) if heads: return " ".join(t.strip() for t in heads if t.strip()) caps = table.xpath(".//caption//text()") return " ".join(c.strip() for c in caps if c.strip()) def parse_table(table): rows = [] for tr in table.xpath(".//tr"): cells = [ " ".join(td.itertext()).strip() for td in tr.xpath("./td|./th") ] cells = [c for c in cells if c] if len(cells) < 2: continue nums = PCT.findall(" ".join(cells)) if not nums: continue item = cells[0] share = float(nums[0]) delta = float(nums[1]) if len(nums) > 1 else None rows.append((item, share, delta)) return rows

上面这段是纯解析，没有任何网络动作，方便你单独测。接下来是抓取和落库。这里有个工程上的细节我要强调：先落库再分析，不要抓完直接在内存里画图。因为页面是滚动更新的，你今天抓到的数据明天可能就变了，只有落库的时间序列才是你唯一的资产。

def crawl(): conn = sqlite3.connect("hwsurvey.db") conn.execute( """ CREATE TABLE IF NOT EXISTS survey( snap TEXT, category TEXT, item TEXT, share REAL, delta REAL, url TEXT, crawled_at TEXT, PRIMARY KEY(snap, category, item) ) """ ) snap = dt.date.today().strftime("%Y-%m") now = dt.datetime.now().isoformat(timespec="seconds") total = 0 for url in PAGES: resp = requests.get(url, headers=HEADERS, timeout=20) resp.raise_for_status() doc = html.fromstring(resp.text) for table in doc.xpath("//table"): category = table_title(table) or "unknown" for item, share, delta in parse_table(table): conn.execute( "INSERT OR REPLACE INTO survey " "(snap, category, item, share, delta, url, crawled_at) " "VALUES (?,?,?,?,?,?,?)", (snap, category, item, share, delta, url, now), ) total += 1 time.sleep(2) # 对站点友好一点，也别把自己 IP 弄脏 conn.commit() conn.close() print(f"{snap} 抓取完成，写入 {total} 条") if __name__ == "__main__": crawl()

第一次跑完，先别急着分析，用一句 SQL 看看类别名有没有归错。

SELECT category, COUNT(*) AS n FROM survey GROUP BY category ORDER BY n DESC LIMIT 20;

如果看到一堆unknown，说明前置标题的元素标签和我的假设不一样，去浏览器里右键检查一下真实标签名，把table_title里的h1/h2/h3/h4换掉就行。

3.4 落到SQLite并做时间序列

数据攒够几个月之后，就可以拉曲线了。取 macOS 占比的查询大概是这样，注意用LIKE 'macOS%'做宽松匹配，因为版本号一直在变。

import sqlite3 import pandas as pd import matplotlib matplotlib.use("Agg") import matplotlib.pyplot as plt # Mac 上画中文必须显式指定字体，否则全是方框 plt.rcParams["font.sans-serif"] = [ "PingFang SC", "Hiragino Sans GB", "Arial Unicode MS", ] plt.rcParams["axes.unicode_minus"] = False conn = sqlite3.connect("hwsurvey.db") sql = """ SELECT snap, SUM(share) AS mac_share FROM survey WHERE category LIKE '%OS%' AND (item LIKE 'macOS%' OR item LIKE 'MacOS%' OR item LIKE 'OSX%') GROUP BY snap ORDER BY snap; """ df = pd.read_sql(sql, conn) df["ma6"] = df["mac_share"].rolling(6, min_periods=1).mean() ax = df.plot(x="snap", y=["mac_share", "ma6"], figsize=(12, 5)) ax.set_xlabel("月份") ax.set_ylabel("macOS 占比 (%)") plt.tight_layout() plt.savefig("mac_trend.png", dpi=150) print(df.tail(12))

这里有两个我自己踩过的坑，直接告诉你省时间。第一，不要对月度值做同比，样本量太小，同比出的数字经常离谱；用 6 个月移动平均看形状就够了。第二，Mac 上 matplotlib 的中文字体一定要设，PingFang SC是系统自带的，设完不用额外装字体文件。

3.5 用launchd把它变成每月自动任务

Mac 上的定时任务别用crontab，用launchd更稳，因为 Mac 睡眠唤醒之后cron经常错过时间点，launchd会在唤醒后补跑。在你的用户目录下建一个 plist 就行。

mkdir -p ~/Library/LaunchAgents

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>local.hwsurvey</string> <key>ProgramArguments</key> <array> <string>/Users/你的用户名/scripts/hwsurvey/.venv/bin/python</string> <string>/Users/你的用户名/scripts/hwsurvey/crawl.py</string> </array> <key>WorkingDirectory</key> <string>/Users/你的用户名/scripts/hwsurvey</string> <key>StartCalendarInterval</key> <dict> <key>Day</key><integer>3</integer> <key>Hour</key><integer>10</integer> <key>Minute</key><integer>15</integer> </dict> <key>StandardOutPath</key> <string>/tmp/hwsurvey.log</string> <key>StandardErrorPath</key> <string>/tmp/hwsurvey.err</string> </dict> </plist>

现代 macOS 用bootstrap加载，老的load也还能用但已经过时了。

launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/local.hwsurvey.plist launchctl list | grep hwsurvey

跑一个月之后看/tmp/hwsurvey.err有没有报错。我建议固定每月 3 号抓，因为月初页面刚更新完，数据最完整，也避开了月末的更新窗口期。

4. 数据之外：Mac玩家体感变多的五个真实推手

数字是一回事，体感是另一回事。我身边确实有越来越多的人在 Mac 上装 Steam，而这个变化的来源，其实和硬件调查那条曲线背后的东西不完全一样。

4.1 Apple Silicon 与统一内存

Intel 时代的 Mac 打游戏，最大的问题是热。MacBook Pro 一跑起来风扇狂转，十分钟后开始降频，帧数掉一半。这不是优化问题，是物理问题。Apple Silicon 换掉之后，能效比换了一个数量级，同样性能下功耗和发热大幅下降，长时间游戏的体验从"能不能玩"变成了"稳不稳"。

统一内存也是个被低估的点。CPU 和 GPU 共享同一块内存池，省掉了传统架构里显存和内存之间的数据搬运。对于显存需求大的游戏，Mac 上选 16GB 或 24GB 内存的机器，实际可用的"显存"比同价位独显本要宽裕。当然代价是内存带宽是共享的，重负载下 CPU 和 GPU 会互相抢带宽，这也是为什么同价位下 Mac 的表现往往"不差但也不惊艳"。

4.2 Metal 与移植工具链

真正让开发者愿意考虑 Mac 的，是工具链的成本降下来了。以前要为一个用户占比很小的平台单独维护一套渲染后端，投入产出比太低。现在的情况是，苹果这边提供了图形 API 和一套移植辅助工具，能把 Windows 平台的图形调用做转换，让开发者先跑起来，再逐步做原生适配。

这个变化的意义在于，它把"要不要支持 Mac"从一道判断题变成了一道成本题。成本降下来之后，决策就变成了"顺手做一下"。我在观察里发现，很多游戏上 Mac 的方式不是专门的 Mac 团队做的，而是主团队在发布节奏里顺手带上的。

4.3 原生移植与发布节奏的变化

我列几个我自己玩过或者关注过的类型，来说明这个变化是真实存在的，但节奏不均匀。

真正的分水岭不是"有多少游戏支持 Mac"，而是"支持 Mac 的游戏里有多少是发售即支持"。从我个人体验看，发售即支持的仍然偏少，更多是后期追加或者引擎顺手导出，这也解释了为什么硬件调查里的占比涨得很慢——能玩不等于愿意在 Mac 上玩。

4.4 串流与云方案把Mac变成终端

还有一大部分新增的"Mac 玩家"，严格说并不在 Mac 上跑游戏。他们用局域网串流，把家里那台 Windows 主机或者掌机的画面串到 Mac 上，Mac 只是个显示和输入终端。这类玩法对硬件调查的贡献是零，因为上报上去的还是那台主机，但他们的体感是"我确实用 Mac 在打 Steam 游戏"。

局域网串流我自己用了很久，说几个实测经验。有线优先，Wi-Fi 至少要 5GHz 独立频段；主机端用有线接到路由器，Mac 端也尽量有线，串流延迟能压到十几毫秒级别，动作游戏也能接受；编码器优先选硬件编码，软件编码会让主机 CPU 吃满。这套方案的好处是不挑 Mac 机型，M1 的 MacBook Air 也能当很好的终端。

4.5 掌机生态的溢出

掌机的出现带来了一批"低画质可接受"的用户心态变化。很多人第一次意识到，一个游戏降到中低画质、720p，体验也能很好。这种心态平移到 Mac 上，就是"我不追求 4K 全高，我只想在地铁上或者床上玩一会儿"。这个心理门槛一降，Mac 上可玩的游戏池子一下就大了——兼容层能跑起来的那些，都进入了"可以接受"的范围。

5. Mac上跑Steam的实操细节与高频故障

讲完趋势，回到最能帮到人的部分。下面是这几年我在 Mac 上折腾 Steam 攒下来的实操细节和故障处理经验，都是真踩过的。

5.1 Steam客户端本身的几个坑

Mac 版 Steam 客户端是独立维护的，很多 Windows 上的习惯用法在这边不成立。几个我印象最深的问题：右键菜单的行为和 Windows 不一样，触控板双指点击和鼠标右键的响应策略不同，有时候要在系统设置里把辅助点击打开才顺手；客户端的窗口全屏行为和 macOS 自己的全屏空间机制会打架，切出去再切回来偶尔黑屏，Command + Tab切一下通常能恢复。

清理缓存的位置也和 Windows 不一样。Mac 上的缓存主要在用户目录下的应用支持目录里，客户端出问题时，退出 Steam 之后把~/Library/Application Support/Steam/appcache里的内容清掉，重启客户端，能解决八成以上的"界面卡住""商店白屏""服务异常"类问题。这个操作不会影响已安装的游戏本体，只重建界面缓存。

提示：遇到提示服务需要维护或者商店加载异常时，先清缓存，再检查系统时间是否准确。系统时间偏差过大会导致客户端和服务器之间的校验失败，这个坑很隐蔽。

5.2 下载速度上不去的排查顺序

"千兆宽带下载只有十几兆"这个抱怨我见过太多次，尤其在 Mac 用户里。它的原因通常是分层叠加的，按下面的顺序排查基本能定位。

1. 先确认单位。客户端显示的单位很多情况下是 MB/s，宽带宣传的是 Mbps，两者差 8 倍。一千兆带宽理论上限大约一百多 MB/s，看到十几确实是慢了，但看到一百左右是完全正常的。
2. 换下载区域。设置里换一个离你近、负载低的下载区域，速度经常立刻变化。这一步最有效，也最容易被忽略。
3. 看是不是卡在解压。Steam 下载分"下载"和"磁盘写入"两段，如果下载速度显示很高但进度不动，瓶颈在磁盘。Mac 上如果是外接硬盘或者空间快满了，写入会成为瓶颈。
4. 检查 Wi-Fi 频段。Mac 如果连的是 2.4GHz，上限就在那儿。切到 5GHz 或者直接插网线试一次，能一步排除无线问题。
5. 关掉可能干扰的软件。有些安全类、备份类软件会持续占用磁盘或者网络，同步任务跑起来的时候下载会明显变慢，暂停同步再测一次。

把这五步走一遍，剩下的情况基本就是运营商或者服务端的问题了，跟 Mac 没关系。

5.3 家庭共享与家庭组邀请失败的常见原因

"接受家庭邀请失败，提示当前活动无法证明你符合加入条件"这类报错，我遇到过，也帮人排查过几次。这类限制通常和账号所在的国家或地区不一致有关——家庭组的成员需要处在同一个区域，另外账号本身要有一定的正常使用记录。这是平台的风险控制逻辑，不是 bug。

我的处理经验是：先确认双方账号的区域设置一致，再确认账号有没有近期修改过区域；如果都对，等几天再试，风控判断会随时间刷新。我不建议为了绕过这个限制去折腾任何第三方工具，那类工具的风险远大于收益。

5.4 "入库工具""挂刀"这类东西的真实风险

热词里出现了一些第三方的"入库工具"和交易相关的工具，我得直说：这类东西我不碰，也不建议任何人碰。所谓入库工具，多数是通过脚本调用客户端接口，把不属于你的内容塞进库里，这直接违反平台协议，被判定异常轻则收回内容，重则账号受限。风险不是"可能"，是"早晚"。

至于利用饰品市场做价差套利那一类玩法，属于灰色地带。它需要频繁的第三方交易、跨平台转手，中间涉及账号安全和资金安全，出问题基本无解。我见过因为这个把账号搞丢的案例，不值得。

6. 高频问题速查与排查顺序

把上面散落的经验整理成一张表，出问题的时候照着走。

关于最后一个我多说一句：00:0C:29开头是很典型的虚拟化网卡前缀，看到这个前缀基本可以确定是虚拟机，不是真实物理网卡。做网络排查的时候这个判断能省很多时间。

除了表格里的，再补两个独家心得。一是排查顺序永远从最便宜的动作开始：换区域、清缓存、插网线，这三件事加起来三分钟，能覆盖大部分问题，很多人一上来就去重装客户端，纯属浪费时间。二是每次改动只动一个变量，我见过有人一次性换区域、清缓存、重装客户端，最后问题解决了也不知道是哪一步起的作用，下次遇到照样抓瞎。

7. 我自己怎么继续跟踪这件事

我不打算给一个"Mac 玩家会越来越多"或者"不会"的结论，因为这类判断的时效性太短。我更愿意告诉你我是怎么持续跟踪的，你可以用同一套方法自己下判断。

7.1 三个可以自己看的指标

第一个是移动平均的形状，不是单月数字。我只看 6 个月和 12 个月的移动平均，看它是平的、缓慢上翘还是横盘。单月的跳变我一律归到噪声里，不做解读。

第二个是 Mac 样本内部的结构。Apple Silicon 在 Mac 样本里的占比，是我认为最有信息量的一个数。它反映的不是"Mac 玩家多不多"，而是"Mac 玩家的机器能不能打"。这个数在我自己的库里，是很早就出现了反转的——新机的占比很快超过了老机型。

第三个是"发售即支持"的比例。这个指标没有官方数据，只能手工统计。我自己的做法是每个月从关注列表里挑一批新发售的游戏，记录它们的 Mac 支持状态，长期下来能看出一个比值。这个比值比占比更能说明开发者态度。

7.2 Mac玩家的配置建议与心态建议

配置上，如果主要目的是打游戏，我的优先级排序是：内存 > 存储 > 芯片档次。内存决定你能不能开高画质、能不能跑内存占用大的游戏，16GB 是底线，24GB 会舒服很多；存储一定要留出足够空间，现在很多游戏本体就上百 GB，加上下载缓存和解压临时空间，512GB 会很快吃紧；芯片档次反而是最后考虑，因为中高配之间的游戏表现差距，远小于内存和存储带来的差距。

心态上，我觉得最重要的一点是别拿 Mac 去对标专门的游戏本。它的优势在便携、续航、静音、屏幕，游戏只是它的一个附加能力。把这层预期摆正之后，你会发现它可玩的游戏其实比你想的多，踩的坑也比你想的少。我自己现在的主力组合就是：轻量游戏直接原生跑，重一点的走兼容层，最重的那个留给串流。这套组合用了两年多，稳定得让我有点意外。