在基于Flutter 开发鸿蒙版GitCode口袋工具的过程中，从功能实现到环境适配，我遇到的影响开发的问题。
问题一：Token配置泄露风险与401授权失败
问题表现
开发初期直接在 app_config.dart 中硬编码GitCode Access Token，不仅存在代码提交时泄露的安全隐患，还频繁出现"Token无效或权限不足"的401错误，导致用户搜索功能完全无法使用。即使替换为正确的个人令牌，部分场景下仍会触发授权失败提示，排查时难以定位问题根源。
成因分析
- 安全配置缺失：硬编码Token违反敏感信息管理规范，若代码上传至公开仓库，极易被他人盗用；且未采用 .env 文件或鸿蒙安全存储（如 Preferences ）进行加密存储，不符合生产环境要求。
-
权限与校验漏洞：新建Token时未勾选"用户搜索""仓库访问"等核心权限，导致API调用时权限不足；同时代码中未对Token格式（如是否包含特殊字符）、有效期进行校验，无效Token直接传入接口引发401错误。
-
请求头逻辑缺陷：初期 _buildHeaders 函数在Token为空时仍附加空的 Authorization 头，干扰GitCode API的鉴权判断，部分情况下被识别为非法请求。
解决方案
-
分级存储Token：开发环境使用 .env 文件存储Token，通过 flutter_dotenv 插件读取，避免硬编码；生产环境集成鸿蒙 Preferences ，将Token加密存储在本地，调用时动态读取，代码中仅保留占位符（如 <你的GitCode个人访问令牌> ），并在注释中强调安全存储要求。
-
完善Token校验与权限配置：在 AppConfig 中添加Token格式校验（如正则匹配Token长度与字符类型），启动APP时先校验Token有效性；新建Token时严格勾选"用户信息读取""仓库搜索""public_repos访问"权限，到期时间设置为1年以内，降低泄露风险。
-
优化请求头逻辑：修改 _buildHeaders 函数，仅在Token非空且长度符合要求时，才附加 Authorization: Bearer <token> 头，避免空header干扰鉴权。同时在 GitCodeApiClient 中捕获401错误时，增加"检查Token权限与有效性"的用户提示，引导快速排查。
问题二：搜索结果解析异常与UI适配混乱
问题表现
调用 searchRepositories 接口时，部分仓库的"Star数量"显示为 null ，且私有仓库的 isPrivate 字段有时显示为 false （实际为私有）；在鸿蒙手机小屏设备上，搜索结果卡片的"语言标签""更新时间"等信息重叠，文字溢出显示不全，影响用户阅读体验。
成因分析
-
数据模型兼容性不足：GitCode API存在字段命名差异，部分仓库返回的Star数量字段为 stars_count （历史版本），而非默认的 stargazers_count ，未做兼容处理导致解析失败； isPrivate 字段返回值可能为 0/1 （数字）或 "true"/"false" （字符串），原代码仅按布尔值解析，导致类型不匹配。
-
UI布局未适配小屏：结果卡片使用固定宽度的 Row 布局承载"语言""Star""Fork"标签，未考虑鸿蒙设备多样的屏幕尺寸；文字未设置 maxLines 与 overflow 属性，长链接（如仓库URL）直接超出卡片边界。
解决方案
-
增强数据模型鲁棒性：在 GitCodeRepository 模型的 fromJson 方法中，优化字段解析逻辑------Star数量优先读取 stargazers_count ，若为 null 则回退至 stars_count ，通过 _safeInt 工具函数兼容数字与字符串类型； isPrivate 字段使用 _safeBool 函数，统一处理 0/1 "true""false"等多种格式，确保解析结果准确。
-
适配鸿蒙多屏UI：将结果卡片的标签布局从 Row 改为 Wrap ，设置 spacing: 8 与 runSpacing: 4 ，让标签在小屏上自动换行；文字部分统一设置 maxLines: 2 与 overflow: TextOverflow.ellipsis ，长描述与URL自动省略；同时使用鸿蒙系统的 MediaQuery 获取屏幕宽度，动态调整卡片内边距，确保在手机、平板等设备上均显示正常。
通过针对性解决Token安全与解析适配两大问题，GitCode口袋工具不仅满足了GitCode API的鉴权要求，还实现了鸿蒙多设备的流畅体验。开发过程中，提前考虑敏感信息管理、API兼容性与跨设备适配，能有效减少后期调试成本，提升工具的稳定性与实用性。