先建立更新前基线
记录电脑平台、系统版本和三项当前能正常完成的日常任务，例如打开常用页面、读取书签和处理少量标签页。
现有资料没有实时 Opera 版本号或更新机制，因此不抄旧截图。需要动态版本信息时，在执行当日回官方页面查看。
完成“先建立更新前基线”后，在桌面更新准备记录中写明依据页面、检查时间、设备原始信息和结论；缺少任何一项时保留为未确认，不用经验补齐。表格末尾再写下一步由谁核对、去哪个官方页面，以及什么结果才能解除阻断。
证据不足时停在核对步骤，比用未经确认的下载或设置继续推进更容易排查。
- 记录平台版本
- 选择三项任务
- 不复制旧版本号
Windows 同时核对系统与 SSE2
官方要求为 Windows 10 或更高版本，并要求支持 SSE2。更新前把系统版本和处理器条件分别记录。
Windows 7、8、8.1、XP 或 Vista 应转入旧系统分支，不能继续套用当前 Windows 常规更新判断。
交接“Windows 同时核对系统与 SSE2”时，让复核人从相同官方 URL 重新开始，并对照同一设备字段复做一次；两次结果不一致就暂停后续动作并保存差异。复核人不能只重复上一人的结论，应留下自己看到的页面位置和设备字段。
页面有变化时先更新记录，再决定是否需要重新选择入口或调整后续检查。
- Windows 10+
- SSE2 条件
- 旧系统另行分流
macOS 用大版本作门槛
官方要求页写明 macOS 12 或更高版本。更新前先确认大版本，低于 12 时应先处理系统条件或查看官方说明。
当前事实没有芯片、安装格式或权限提示细节；遇到相关问题时保留系统原文，不自行写成确定兼容结论。
如果“macOS 用大版本作门槛”得到否或未知，表格应保留原始文字和下一条核对路径；不要为了完成桌面更新准备清单而把条件改写成已经满足。只有来源、设备与选择三者能够对应，才把该项标记为通过并进入下一步。
这一条的目标是形成可重复判断，不是把所有未知情况都写成肯定答案。
- 确认 macOS 12+
- 保留系统提示
- 不推断芯片
Linux 四项放在一行核对
Linux 同时检查受支持发行版、最低版本、64 位和 SSE3。建议把四项放在一张表里，缺一项就保持未完成。
公开范围为 Ubuntu 18.04+、Debian 10+、openSUSE 15.2+、Fedora 32+；衍生系统和具体命令不在现有事实内。
这一项只记录来源能够证明的内容。与“Linux 四项放在一行核对”有关但未在当前三张官方页面出现的版本、文件、账户或行为细节，都单列为待官方确认。站内建议可以说明如何留痕，却不能替 Opera 作兼容、支持或恢复承诺。
读者看到未知项时应能直接找到官方复核位置，而不是被引向非官方猜测。
- 发行版版本
- 64 位
- SSE3
按 Sync 类别盘点资料
Opera Sync 页面列出书签、快速拨号、密码、历史记录与已打开标签页。更新前逐类登记需要保留、无需保留或尚未确认。
类别存在不等于设备已经同步。当前来源也没有账户恢复、加密、容量或完成时间细节，实际状态仍需本机核对。
复核人应先读“按 Sync 类别盘点资料”对应的设备信息，再打开官方页面，不从结论倒推证据；这样后续即使页面变化，也能区分现场信息和网页更新。完成后保留页面地址与日期，不把缓存页面、搜索摘要或转述当成同级依据。
复查记录只保存完成任务所需信息，不收集密码、完整历史或私人页面内容。
- 五类逐项登记
- 能力与状态分开
- 账户细节回官方确认
旧系统只引用归档线索
官方下载页仍列出 Windows 7、8、8.1 对应 Opera 95，以及 XP、Vista 对应 Opera 36。它们只用于识别旧系统边界。
不得把归档编号扩写成安全承诺、推荐版本或长期维护结论。本站不托管旧安装包，也不从第三方补包。
为“旧系统只引用归档线索”保留通过、阻断、未确认三种状态，并在状态旁写下一步动作。状态名称保持明确，避免使用“应该可以”这类无法验收的描述。若任务转交他人，接手者应能仅凭这条记录重现核对路径，而无需猜测前一步做过什么。
若责任人变化，新的执行者仍应重做关键判断，不能沿用口头确认作为证据。
- 归档只作识别
- 不作安全承诺
- 不托管旧包
更新后重复同一组检查
执行后用相同设备、相同网络条件和相同三项任务复核，再看所需书签、密码与标签页是否符合预期。
单次体感不能形成性能结论。异常应记录时间、页面、错误提示和是否可重复出现，以便精确求助。
每次重做“更新后重复同一组检查”都更新检查日期，但不要覆盖旧结果；保留前后记录能看出设备变化、页面变化或操作差异究竟发生在哪一处。若内容冲突，先暂停下载、安装或资料迁移，再以执行当天的官方页面和设备原始信息复核。
任何下载或安装动作都排在条件核对之后，顺序变化应作为流程偏差记录。
- 同项对照
- 保存异常原文
- 不写单次体感结论
未解决项按官方页面分流
系统问题回要求页，下载或归档问题回下载页，同步类别问题回 Sync 页面，不把所有情况笼统写成更新失败。
清单末尾留下已通过、未通过和未核验项。官方页面若变化，以新内容为准并更新自己的记录。
将“未解决项按官方页面分流”的最终结果连同官方地址放入桌面更新准备交接摘要，敏感资料只写类别不写内容；官方事实和本地建议分别标注。摘要还应列出尚未解决的项目、负责人和复核条件，不能用一条笼统的“已完成”覆盖遗留问题。
交付时保留未解决项，能避免下一次维护把旧问题误认为已经通过。
- 问题按来源分流
- 三类状态明确
- 官方内容优先