修复 issue report 中 board 链接失效，并完善移动端体验与任务标签体系

TL;DR

• 定义：本文将“board”视为独立站点 board.zondev.top 的全局看板；“新增”指新建/新入库的任务条目。
• 修复优先级：先把 issue report 里的 board 链接改为“配置化 + 统一 URL 生成函数”，并补自动化回归校验，避免再次断链。
• 体验补齐：issue report 复用 board 已有的移动端适配策略；移动端卡顿用“loading/skeleton + 分页/虚拟列表 + 按需请求/渲染”落地优化。

Key Insights

• 链接失效常见来源：域名迁移后仍硬编码旧地址；子目录部署导致相对路径错位；反向代理缺少 SPA history fallback（直达/刷新 404）。
• diary.zondev.top/research 与 board.zondev.top 看起来是两套前端/部署，联动应先定“深链接协议”（入口、参数、默认筛选），再做跳转拼装与解析。
• “board 已适配、report 未适配”通常意味着样式体系未复用（组件库/Token/断点不一致），应尽量合并到同一套布局与响应式规则。
• “移动端加载很卡”往往与全量拉取与全量渲染有关（一次渲染大量卡片/Markdown）；需要先量化（LCP、TBT、请求数、首屏卡片数）再制定优化顺序。

Playbook

• 复现与取证：在桌面/移动端打开 issue report 页面，复制 board 链接 href；记录点击后的状态码/跳转链、控制台报错、网络请求（是否跨域被拦）。
• 代码定位：仓库内全局搜索 "board.zondev.top"、"/board"、"board"；把链接拼接收敛到 util（如 getBoardUrl），并只从环境变量读取 BOARD_BASE_URL。
• 生成规则：使用 new URL(path, base) 组装，统一处理尾斜杠、URL 编码、查询参数（例如 issueId、tag、type）；base 未配置时做降级（隐藏入口或提示配置）。
• 防回归：加 Playwright/Cypress e2e，断言 issue report 页面存在正确 href；若有预发环境，可做轻量可达性校验（目标非 404）以捕获路由/部署回归。

Expert Views

• 前端工程师（paraphrase）：链接生成必须单一入口与配置化，避免在模板/Markdown 中散落硬编码；移动端适配优先复用既有组件与断点体系。
• Web 性能工程师（paraphrase）：不要先猜，先用 Lighthouse 与 Performance trace 建立基线；优化顺序通常是减少首屏渲染量、按需加载、虚拟列表、缓存与压缩。
• 产品/流程负责人（paraphrase）：先明确 board 的定位与信息架构（全局任务 vs research 专用），再决定 issue report 跳转携带的筛选条件与默认视图，避免“能跳但找不到”。
• 安全/运维工程师（paraphrase）：跨站点联动与 GitHub 数据聚合时要避免前端暴露 Token；如需服务端代理，建议做缓存、速率限制与错误兜底，减少移动端抖动。

Options

• 方案 A（board 为独立全局看板）：issue report 生成绝对链接到 board.zondev.top，并携带参数（如 ?src=issueReport&issue=26&type=research）；board 端解析参数并定位/高亮对应卡片。
• 方案 B（board 指 GitHub Projects/Issues 看板）：issue report 直接链接到对应 Project 视图 URL；需要先确认是否使用 Projects v2，以及目标视图是否稳定可分享。
• 方案 C（board 应为 diary 站内路由）：将 board 通过同域路径挂载（如 diary.zondev.top/board），统一 basePath 与静态资源路径，减少跨域复杂度与 Cookie/缓存割裂。
• “新增做样式/事务性标签”落地：以 GitHub label 或笔记 frontmatter 做判定（例 type/ops、type/research、status/*），UI 上提供筛选与一键切换；新增条目可用“创建时间 < N 天”或显式 label:new 触发高亮样式。

Evidence & Confidence

• “链接生成收敛到 URL builder + 环境变量”置信度 high：多域名/多环境部署下，硬编码与字符串拼接是最常见断链根因，且修复成本低、收益高。
• “report 页面移动端样式可通过复用断点/组件库修复”置信度 medium：从描述推断成立，但无法在线核验当前 report 页 DOM/CSS 结构与约束条件。
• “移动端卡顿主要由全量渲染/请求导致，需 skeleton+分页/虚拟列表”置信度 medium：高度符合列表/看板类页面典型瓶颈，但仍需用性能数据验证具体瓶颈点。
• “用 labels/frontmatter 区分事务 ops 与调研 research”置信度 medium：与现有 issue/看板工作流契合度高，但需确认你当前数据源与同步方式（是否直接读 GitHub Issues）。

Next Steps

• 先确认两个歧义点：board 目标是 board.zondev.top 还是 GitHub Projects/站内路由；“新增样式”是指新建任务高亮还是新功能 UI 风格统一。
• 提供一个失效链接样例：从 issue report 页面复制实际 href，并附点击结果（404/空白/跳转到错误页面）与设备信息（iOS/Android/桌面）。
• 输出最小联动规范：board 支持的 query 参数（issueId、type、tag、repo 等）、默认筛选逻辑、以及从 board 返回 report 的入口。
• 建立移动端性能基线：Lighthouse mobile（LCP、TBT、请求数）与目标阈值；按“loading/skeleton、分页/虚拟列表、按需渲染 Markdown/卡片、缓存”逐步上线并回归验证。

Sources

• 现场页面（无法在线核验）：https://diary.zondev.top/research/ 与 https://board.zondev.top
• GitHub Issue（无法在线核验实时内容）：https://github.com/EOMZON/myObsidian/issues/26
• GitHub REST API - Issues：https://docs.github.com/en/rest/issues/issues
• Playwright 文档：https://playwright.dev/docs/intro