怎么好像描述的是反过来的……
https://imgur.com/a/y5GDiJt

安卓机顶盒都支持，没理由砍掉这个原生功能。

直连的话，服务器装一下 Google 的 BBR 看看有没有改善

em, Surface Pro 系列作为主力机的话，如果不仅仅是做文字工作，感觉屏幕过小。我有个 15 寸的 Book 2 和一个当作备用机的 Pro 4 这样，因为 Pro 8 换模具了所以不清楚有没有太多变化…… 简单聊一聊使用体验吧。

- Surface Type Cover (磁吸键盘) 体验良好，很合格。Book 系列和 Laptop 系列更不用说。而且 Surface 系列的键盘很难得地没有将一些功能键给砍掉 (比如菜单键)，相对于其他各路笔记本的键盘设计来看是最标准的 Windows 该有的键盘布局。

- 屏幕没遇到过问题，Surface Book 2 15' 有屏幕残影现象，但这个是新机就有的所以等于不会随使用时长变差。Pro 系列较新的型号已经基本不会出现屏幕品控问题了。(另外，Book 系列已经停止发布新品了，估计微软也意识到了这个设计的不实用。现在是 Surface Laptop Studio 作为最高配设备在卖)

- 如果发现屏幕出现一块黄点或者一条的那种，不少是电池鼓包顶上来造成的。换了电池之后，屏幕会是老样子，基本是完好的。

- 如果要使用 Surface Pen…… 呃，和 Apple Pencil 使用体验对比了之后就不太想用 Surface 的笔了，一个是屏幕热，烫手掌；另一个是 Surface 系列的低压 U 加上发热问题，基本不允许 Photoshop 之类的大型软件有良好体验，Adobe Fresco 也一样。更新的型号因为自己没试过，也不好确定有没有改善。如果附近有微软实体店的话可以先去试一下。

- 我那台 Pro 4 异常耐用，Book 的话电池反而挂过，不过那时候都过保了，还算行。换过电池，此外没有维修过。官方维修服务没在 Surface 上用到过，没有能够分享的……

- 另外，Book 的磁吸充电口会接触不良，因为它的侧边是平的。Pro 系列的侧边是有倾角的所以没遇到这种情况。

- 补充一下续航：Surface 设备在 Windows 下的电池模式设置会直接影响到给 CPU 分配的功率。不插电使用时，“推荐”电源模式下续航非常给力，但这是牺牲性能换来的，使用时会有一些感觉。插电使用时如果开到最高性能，留意一下散热情况，可能会过热降频。……也就是说，这些电源模式是确实调教好了的，还算有诚意。


呃，如果要总结最突出的问题的话，就是 发热时书写体验差、受低压 U 限制性能 和 屏幕较小。屏幕尺寸可能不会是大问题，我估计是因为 15 寸设备用惯了吧，但 Surface 默认的 200% 缩放比会比同尺寸的 Mac 显示利用率低一些 (? 存疑)，不过 13 寸的其他 Windows 笔记本基本没有同样屏幕比例和显示素质的，所以也没想出哪些设备可以横向对比。可以去实体店先试一下？

哦，搂上外壳带电的情况咱也有。看样子是金属外壳难免的。对于磁吸键盘，它不能侧着使用 (想一下侧着身躺着用笔记本电脑的时候电脑架的角度，就是那种)，只有接近正常摆在桌上的那种角度才行。不清楚为什么这么设计。

(另外，国内的微软保修貌似已经是只修不换了？)

USB 转视频采用的是驱动程序模拟一块屏幕、然后处理视频流传给 USB 设备进行输出，不是原生视频输出。我个人感觉兼容性可能不会太好，因为这一套绕了弯路的视频输出流程本身就不是很标准。

如果是 Windows 系统，装个驱动应该就解决了。我遇见过 Windows 10 是可以走系统自动更新通道来自动给一些 USB 显卡打驱动，可以留意一下是不是系统更新被关闭了。手动安装驱动的话去产品说明里面找找看。

@NeedforV2 Server Side Rendering ，即服务端渲染，不执行页面的任何 JavaScript 脚本的情况下，要保证页面上必要的内容完整。百度的爬虫目前不支持执行 JS 来完成页面的渲染工作。
典型的例子就是，掘金 (稀土掘金) 的所有文章只有 Google 能够搜索到，百度无记录。

A Short Hike

流程较短，但很精致

试一下改为 zh-CN?

你看一下 Userscripts 不能正确运行的那些脚本，代码开头的注释部分是不是将匹配的 URL 规则写在了 @include 后面，把它改成 @match 试试看。

首页条幅里面一直没见过，搜索倒是一下就有了，差点错过。感谢提醒
这个游戏很早的时候在 XGP 耍过，有很精致的感觉，但没有大段时间游玩下去就先丢掉了，倒是把几个高分平台动作类作品优先耍了个遍。
iPad 上下载后留意到似乎不能使用手柄？好像检测到了，但提示“控制器断开连接”之后就没有动静了。不清楚是不是个例。

就如上面所说的，日版 5GHz 的信道范围和国内重合部分较少，路由器的 5GHz 信道会建议设置为两位数固定值。别的无事。

@MossFox 整忘了，快速指定静态文件类型然后直接生成的工具是 Workbox wizard ，看上面页面的 wizard 条目就好

@MossFox 整忘了，快速指定静态文件类型然后直接生成的工具是 Workbox wizard ，看这个 https://developer.chrome.com/docs/workbox/modules/workbox-cli/#wizard

如楼上说的一致，Service worker 可用帮助缓存。如果需要快速生成可用的 Service Worker ，使用 Google 的 workbox-cli 可用直接指定要缓存的文件类型，帮你创建好 sw.js ，几乎可用不用手写代码。

https://developer.chrome.com/docs/workbox/modules/workbox-cli/

留意一下，采用这种方法的话，如果静态文件有更新，每一次也要充新生成一下 sw.js 。在用户完全退出页面后可自动完成更新。
(如果要强制在页面刷新的时候就丢掉旧的 Service Worker 并载入新的静态文件 (即 skip waiting)，可在检测已有新的 service worker 在等待的时候，向新安装的那个 postMessage 来实现，具体参考谷歌的文档就好)

因为这个 [页面刷新时不会立即应用更新] 可能是个坑，所以我就多啰嗦了一点。下面是我以前写过的一个解决此问题的例子，要是会用到的话可用参考下。

```
window.addEventListener('load', async () => {
try {
let reg = await navigator.serviceWorker.register('/sw.js');
if (reg) {
// listen for update
reg.addEventListener('updatefound', () => {
let worker = reg.installing;
worker.addEventListener('statechange', () => {
if (worker.state === 'installed') {
worker.postMessage({
type: "SKIP_WAITING"
});
}
});
});
// one update already installed
if (reg.waiting) {
reg.waiting.postMessage({
type: "SKIP_WAITING"
});
}
}
} catch (err) {
console.log(err);
}
});

```

浏览器安装 React Developer Tooks 与 Vue Devtools ，在对应页面亮起来的就说明有用到对应框架。

但，好久之前就留意到有个比较奇怪的现象，我一直没摸清楚到底是什么情况，
在例如这里 → https://fontawesome.com/icons/hexagon-image?s=solid
两个插件图标会 [同时亮起来] ，很诧异，是真的混用了两个框架还是说有存在误判？

有个可能需要留意的小区别，因为网卡配置不能自定义，轻量云是不支持分配 IPv6 的。
(当然也不是没有方案，可以用云联网来结合同地域下的另一台标准云服务器的流量转发来间接实现 v6 访问)

不太清楚是什么情况，但，这文本直接就是一个有效的 JavaScript 对象，
用 JSON.stringify 得到的 JSON 字符串是这样 👇
'{"version":"2.0","msg":"{\\"order_id\\":\\"1234\\",\\"goods\\":[{\\"img_url\\":\\"http://baidu.com/1.jpg?bd-rpc-level=pt,1_1,2\\",\\"title\\":\\"审核商品\\",\\"sub_title\\":\\"\\",\\"labels\\":\\"免 E\\",\\"date_rule\\":\\"\\",\\"origin_price\\":1,\\"price\\":1,\\"quantity\\":1,\\"poi_id\\":\\"\\",\\"goods_id\\":\\"1\\",\\"item_order_id_list\\":[\\"ot223\\"],\\"goods_id_type\\":2}],\\"total_amount\\":1,\\"discount\\":0,\\"cp_extra\\":\\"{\\\\\\"scene_id\\\\\\":\\\\\\"990001\\\\\\"}\\",\\"create_order_time\\":1647934340045,\\"open_id\\":\\"b8a100eb-8b77-4f2c-8ad3-995bd57593f6\\",\\"phone_num\\":\\"15036100938\\",\\"contact_name\\":\\"\\",\\"app_id\\":\\"T3122\\",\\"union_id\\":\\"uuid\\"}","type":"set_order"}'

可以看出问题大约是在 msg 的字符串里面发生的。如果是前后端交互，前端发送给后端的文本应该是 stringify 之后的字符串（然后后端 parse 一下，得到一个有效的对象）。从本地读取 JSON 文件则不需要。

...我知道的就这些了，看看有没有帮助

无线信道问题有没有检查过？像是日版的一些设备，5 GHz 频段的信道标准和国内只有小部分重合，路由器设置的信道是三位数则日常无法被连接。可以看下会不会是这个问题。

美版的话只有 2.4 GHz 的 12 、13 信道不会被扫描，其他貌似全覆盖。