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 玩家是不是变强了也最有意思。我把这三个口径整理成一张对照表你可以拿它去判断别人跟你争论时到底在说哪一层。口径单位主要回答的问题常见误导占比百分比Mac 在 Steam 大盘里的分量分母被 Windows 稀释看着永远很低绝对值台/人实际有多少 Mac 在开机打游戏依赖 Steam 官方月活估算误差不小结构百分比Mac 样本里谁在增长容易被新机型发布短期扭曲我的建议是跟人讨论的时候先锁定口径别跨着聊。你拿占比去说服一个拿体感的人基本说服不了反过来也一样。1.2 为什么官方调查的百分比会骗人Steam 硬件调查是个自愿上报的抽样调查不是全量统计。它的样本来自当月登录过 Steam 并且被抽中弹窗提问的用户这中间有几层筛选每一层都会往某个方向偏。第一层偏在会不会被抽中。样本量相对 Steam 的体量来说并不算大当某一类设备在总样本里只占一两个百分点时几百台的波动就能让百分比抖动零点几个点看上去像断崖或暴涨其实可能只是抽样的噪声。第二层偏在谁愿意上报。装了新机器的人更愿意点是这会让新机型在调查里被高估一小段时间。第三层偏在谁在真正打游戏。很多人的 Mac 是工作主力机Steam 常年只挂着不玩这类账号如果被抽中会把 Mac 的游戏含量进一步稀释。注意把月度百分比当成精确测量值去算增速、算复合增长率是没有意义的。它的置信区间比很多人想象的要宽得多。看趋势至少要看 6 到 12 个月的移动平均。这也是我为什么决定自己攒数据不是我不信官方而是我需要看到连续的、可以自己算平滑曲线的原始序列而不是每个月看一眼新闻标题里那一句macOS 占比 XX%。1.3 我用的数据源和取舍我能拿到的数据源大概就这么几类各有各的毛病最后我是组合使用的。数据源拿到什么优点缺点Steam 硬件调查页面当月操作系统、CPU、显卡、显存、内存分布官方口径免费结构清晰只保留当期历史不留档第三方存档站点历史月度快照省事能直接看长周期口径可能被二次加工得核对Steam 客户端本地日志你自己的机型、下载区域、耗时完全可信只有你一台机器的样本游戏发行商公开访谈Mac 版卖得怎么样这类定性说法一手信息极少且带宣传动机我最后的做法是以 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 python3.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 matplotlibIntel 机型的 Homebrew 前缀是/usr/localApple 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;q0.9,en;q0.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(timespecseconds) total 0 for url in PAGES: resp requests.get(url, headersHEADERS, timeout20) 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_periods1).mean() ax df.plot(xsnap, y[mac_share, ma6], figsize(12, 5)) ax.set_xlabel(月份) ax.set_ylabel(macOS 占比 (%)) plt.tight_layout() plt.savefig(mac_trend.png, dpi150) print(df.tail(12))这里有两个我自己踩过的坑直接告诉你省时间。第一不要对月度值做同比样本量太小同比出的数字经常离谱用 6 个月移动平均看形状就够了。第二Mac 上 matplotlib 的中文字体一定要设PingFang SC是系统自带的设完不用额外装字体文件。3.5 用launchd把它变成每月自动任务Mac 上的定时任务别用crontab用launchd更稳因为 Mac 睡眠唤醒之后cron经常错过时间点launchd会在唤醒后补跑。在你的用户目录下建一个 plist 就行。mkdir -p ~/Library/LaunchAgents?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keyLabel/key stringlocal.hwsurvey/string keyProgramArguments/key array string/Users/你的用户名/scripts/hwsurvey/.venv/bin/python/string string/Users/你的用户名/scripts/hwsurvey/crawl.py/string /array keyWorkingDirectory/key string/Users/你的用户名/scripts/hwsurvey/string keyStartCalendarInterval/key dict keyDay/keyinteger3/integer keyHour/keyinteger10/integer keyMinute/keyinteger15/integer /dict keyStandardOutPath/key string/tmp/hwsurvey.log/string keyStandardErrorPath/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 版体验最稳帧数可预期后期补丁追加上线几个月到一年后支持优化水平参差看团队投入引擎自带支持用同款引擎的项目顺手导出能跑但细节打磨不足兼容层运行靠转换工具跑 Windows 版能玩兼容性看运气真正的分水岭不是有多少游戏支持 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 用户里。它的原因通常是分层叠加的按下面的顺序排查基本能定位。先确认单位。客户端显示的单位很多情况下是 MB/s宽带宣传的是 Mbps两者差 8 倍。一千兆带宽理论上限大约一百多 MB/s看到十几确实是慢了但看到一百左右是完全正常的。换下载区域。设置里换一个离你近、负载低的下载区域速度经常立刻变化。这一步最有效也最容易被忽略。看是不是卡在解压。Steam 下载分下载和磁盘写入两段如果下载速度显示很高但进度不动瓶颈在磁盘。Mac 上如果是外接硬盘或者空间快满了写入会成为瓶颈。检查 Wi-Fi 频段。Mac 如果连的是 2.4GHz上限就在那儿。切到 5GHz 或者直接插网线试一次能一步排除无线问题。关掉可能干扰的软件。有些安全类、备份类软件会持续占用磁盘或者网络同步任务跑起来的时候下载会明显变慢暂停同步再测一次。把这五步走一遍剩下的情况基本就是运营商或者服务端的问题了跟 Mac 没关系。5.3 家庭共享与家庭组邀请失败的常见原因接受家庭邀请失败提示当前活动无法证明你符合加入条件这类报错我遇到过也帮人排查过几次。这类限制通常和账号所在的国家或地区不一致有关——家庭组的成员需要处在同一个区域另外账号本身要有一定的正常使用记录。这是平台的风险控制逻辑不是 bug。我的处理经验是先确认双方账号的区域设置一致再确认账号有没有近期修改过区域如果都对等几天再试风控判断会随时间刷新。我不建议为了绕过这个限制去折腾任何第三方工具那类工具的风险远大于收益。5.4 入库工具挂刀这类东西的真实风险热词里出现了一些第三方的入库工具和交易相关的工具我得直说这类东西我不碰也不建议任何人碰。所谓入库工具多数是通过脚本调用客户端接口把不属于你的内容塞进库里这直接违反平台协议被判定异常轻则收回内容重则账号受限。风险不是可能是早晚。至于利用饰品市场做价差套利那一类玩法属于灰色地带。它需要频繁的第三方交易、跨平台转手中间涉及账号安全和资金安全出问题基本无解。我见过因为这个把账号搞丢的案例不值得。6. 高频问题速查与排查顺序把上面散落的经验整理成一张表出问题的时候照着走。现象最可能的原因排查顺序处理方式商店白屏、提示服务异常客户端缓存损坏先清 appcache再对时清缓存后重启客户端下载只有十几 MB/s单位换算、区域、无线换区域 → 插网线 → 看磁盘换下载区域最有效进度不动但显示在下载磁盘写入瓶颈看剩余空间、看是否外接盘腾空间或换内置盘家庭组邀请被拒区域不一致或风控核对双方区域设置一致后等风控刷新游戏启动闪退兼容层配置问题看兼容层版本、看日志换配置或回退版本客户端界面卡死全屏空间冲突切一次窗口再切回用Command Tab恢复中文输入法在客户端里乱码输入法兼容问题换系统输入法测试用系统自带输入法虚拟机里的 MAC 地址虚拟网卡前缀看是不是 00:0C:29 开头那是虚拟化厂商的固定前缀关于最后一个我多说一句00:0C:29开头是很典型的虚拟化网卡前缀看到这个前缀基本可以确定是虚拟机不是真实物理网卡。做网络排查的时候这个判断能省很多时间。除了表格里的再补两个独家心得。一是排查顺序永远从最便宜的动作开始换区域、清缓存、插网线这三件事加起来三分钟能覆盖大部分问题很多人一上来就去重装客户端纯属浪费时间。二是每次改动只动一个变量我见过有人一次性换区域、清缓存、重装客户端最后问题解决了也不知道是哪一步起的作用下次遇到照样抓瞎。7. 我自己怎么继续跟踪这件事我不打算给一个Mac 玩家会越来越多或者不会的结论因为这类判断的时效性太短。我更愿意告诉你我是怎么持续跟踪的你可以用同一套方法自己下判断。7.1 三个可以自己看的指标第一个是移动平均的形状不是单月数字。我只看 6 个月和 12 个月的移动平均看它是平的、缓慢上翘还是横盘。单月的跳变我一律归到噪声里不做解读。第二个是 Mac 样本内部的结构。Apple Silicon 在 Mac 样本里的占比是我认为最有信息量的一个数。它反映的不是Mac 玩家多不多而是Mac 玩家的机器能不能打。这个数在我自己的库里是很早就出现了反转的——新机的占比很快超过了老机型。第三个是发售即支持的比例。这个指标没有官方数据只能手工统计。我自己的做法是每个月从关注列表里挑一批新发售的游戏记录它们的 Mac 支持状态长期下来能看出一个比值。这个比值比占比更能说明开发者态度。7.2 Mac玩家的配置建议与心态建议配置上如果主要目的是打游戏我的优先级排序是内存 存储 芯片档次。内存决定你能不能开高画质、能不能跑内存占用大的游戏16GB 是底线24GB 会舒服很多存储一定要留出足够空间现在很多游戏本体就上百 GB加上下载缓存和解压临时空间512GB 会很快吃紧芯片档次反而是最后考虑因为中高配之间的游戏表现差距远小于内存和存储带来的差距。心态上我觉得最重要的一点是别拿 Mac 去对标专门的游戏本。它的优势在便携、续航、静音、屏幕游戏只是它的一个附加能力。把这层预期摆正之后你会发现它可玩的游戏其实比你想的多踩的坑也比你想的少。我自己现在的主力组合就是轻量游戏直接原生跑重一点的走兼容层最重的那个留给串流。这套组合用了两年多稳定得让我有点意外。