启动时需在ui渲染前完成历史最高分读取与校验，包括文件存在性、可读性、格式合法性检查，解析失败则启用安全默认值，更新时须同步内存与持久化存储。
启动时正确载入历史最高分记录，核心不是“文件检查”本身，而是确保读取逻辑在UI渲染前完成、容错处理到位、数据结构安全可用。所谓“利用文件检查”，实际是指对记录文件的存在性、可读性、格式合法性做必要验证，避免因文件缺失或损坏导致程序异常或状态错乱。
启动前主动尝试读取并校验文件
游戏初始化阶段（如ArkTS的aboutToAppear()、Java的构造方法、Python的__init__）应立即尝试读取记录文件：
- 先判断文件是否存在（例如用
file.exists()或os.path.isfile()）； - 若不存在，直接跳过解析，使用预设默认值（如最高分设为
Infinity或999，玩家名为空字符串）； - 若存在，再尝试打开并读取内容——这步本身已是隐式“检查”，失败即触发异常捕获流程。
按格式规范解析内容，拒绝非法数据
最高分记录通常为简单结构（如一行姓名+一行分数，或JSON对象），解析时必须严格校验：
- 文本格式：按行分割后，检查是否至少有两行；第一行转为字符串（非空），第二行转为整数且大于0；任一不满足则视为无效，弃用该文件；
- JSON格式：用
JSON.parse()后，检查是否有name和attempts字段，且attempts为正整数；缺少字段或类型错误即丢弃； - 不信任任何外部输入——即使文件存在，也不代表内容合法。
设置安全默认值，保证状态始终可用
无论文件是否存在、内容是否有效，最高分相关状态变量必须有明确初始值：
- 例如：
@State bestScore: number = 999、@State bestPlayer: string = "暂无纪录"； - 这样即使所有读取逻辑失败，UI仍能正常渲染，不会因
undefined或null引发崩溃； - 后续新纪录产生时，再覆盖写入，形成闭环。
写入时同步刷新，避免读写不同步
更新最高分时，不要只写文件而忽略内存状态：
- 先更新内存中的
bestScore和bestPlayer； - 再调用
writeFileSync或await pref.put()持久化； - 写入失败需记录日志，但不中断游戏流程——用户感知应是“本次未保存”，而非“游戏卡住”。
