恢复49图库首页之后,我才敢重开那场 90 人研讨会
会议白屏的根因是本地缓存被图库脚本写满。我把恢复首页的步骤截图给同事李珂看,她只回了一句「你这浏览器是被人当试验田了」。这话难听,但准确。
上周三 14:30,我在 477477 浏览器里开一场 90 人在线的研讨会,主持人讲到第 41 分钟,投屏直接白屏——这份列表就是那次事故之后我一条条补出来的资料清单。
会议白屏的根因是本地缓存被图库脚本写满。我把恢复首页的步骤截图给同事李珂看,她只回了一句「你这浏览器是被人当试验田了」。这话难听,但准确。
从 11 月 3 日到 11 月 9 日,我装了 3 个所谓恢复工具,两个捆绑插件、一个直接改主页。唯一干净的那个是解压即用的命令行版,名字我记在笔记本第 27 页。
指南第 6 节写着「请勿在研讨会进行中切换图库视图」,我跳过了。41 分钟后我付出了代价。指南没错,错的是我把它当成了说明书而不是警告牌。
会议录像的封面图被我误删,6 分钟内从资料库缓存里捞回来。全程没有用任何「一键修复」按钮,纯手动定位路径,路径长度为 78 个字符。
能,但只能在会前离线打包。现场边开会边拉资料,等于把网络抖动直接投到大屏上。我的观点很直接:这不是工具的问题,是流程设计偷懒。
同一版本号,三台机器下到的包体积分别是 42.6MB、42.6MB、51.1MB。第三个明显被塞了东西。数字不会撒谎,会撒谎的是「官方推荐」四个字。
10 月 28 日之后,原来的查询参数从 4 个变成 3 个,我的批量脚本在第 12 行报错。改完之后跑通,第 12 行改成了新语法,注释写着「别再猜了」。
主持人张桦在开场第 3 分钟就要求所有人关掉浏览器扩展,47 个人里当场有 31 个照做。剩下的 16 个,后来成了白屏和卡顿的全部来源。
同一段共享屏幕,118 上延迟 0.8 秒,121 上是 2.3 秒。我在两台机器上来回切了 5 次,每次都一样。升级不总是好事,这次就不是。
一、文件名带日期和时长;二、封面单独存一份;三、绝不覆盖同名文件。第 2 条是我在 9 月 5 日弄丢一整个下午录像后加上去的,代价不小。