修复 issue report 中 board 链接失效问题：联动与移动端体验优化调研

TL;DR

• 本报告中的“board”指向 https://board.zondev.top 的全局看板入口（假设为期望目标）。
• 链接失效常见根因是 research 子路径下使用相对链接/错误 basePath/缺少 https 协议，导致跳到 diary 域或 404。
• 建议把 board 入口与深链规则配置化（如 NEXT_PUBLIC_BOARD_ORIGIN），并补上 e2e 测试防回归。
• 移动端需补齐响应式布局，并用骨架屏+分段加载+懒加载图表/列表虚拟化解决卡顿。

Key Insights

• 若页面路径是 /research/，写成 href="board" 或 "board.zondev.top"（无协议）会被浏览器解析为相对路径（/research/board 或 /research/board.zondev.top），从而失效。
• diary 与 board 为不同子域时，硬编码 URL/路径容易在部署环境、反向代理、trailing slash 上产生漂移；应集中配置“唯一真相”。
• “联动”的最小可行是“深链跳转”（带过滤条件/定位参数）；更进一步才是共享数据源、统一登录、双向状态同步。
• 移动端“加载很卡”通常来自一次性拉取全量数据+大体积图表库/Markdown 渲染；需要拆分接口、延迟渲染与缓存策略配合。

Playbook

• 复现与定位：在 https://diary.zondev.top/research/ 点 board 入口，记录最终跳转 URL、HTTP 状态码、控制台报错与 Network 重定向链；站点现状无法在线核验时，需本地起服务复现并截取 HTML 里的实际 href。
• 修复链接生成：代码全局搜索 "board"/"board.zondev.top"/“看板”，把 href 改为基于配置的绝对 URL（BOARD_ORIGIN + path），避免受 basePath/当前路由影响；外链建议用原生 <a> 并显式加 https。
• 设计联动协议：约定 board 支持的 query/path（例如 /?issue=26&from=diary 或 /issue/26），board 解析后自动应用过滤/定位；同时支持 returnUrl 以便用户回到 issue report 原位置。
• 移动端体验与局部加载：首屏与每个模块分别加 loading/skeleton；长列表用分页/无限滚动或虚拟滚动（react-window）；重组件（图表/代码高亮）用动态导入与按需渲染，必要时按 IntersectionObserver 进入视口再加载。

Expert Views

• 前端架构/全栈工程师（paraphrase）：跨域入口必须配置化且可测试，尤其是 basePath/子路径部署；用 Playwright 覆盖“点击看板必达”的关键链路，避免路由重构引入回归。
• SRE/运维（paraphrase）：先排除 301/302 重定向链、HSTS、CDN 缓存与 trailing slash 规则造成的跳转异常；同时确认两个子域的证书、DNS、缓存规则一致，避免“有时能开有时 404”。
• 移动端性能工程师（paraphrase）：不要只做全局 loading，应按模块拆分加载边界；先测 LCP/INP/CLS 再对症优化（JS 体积、接口耗时、渲染阻塞各自打法不同）。
• 产品经理/信息架构（paraphrase）：先明确 board 的语义（全局入口 vs 当前 issue 视角），再决定默认筛选与深链参数，否则用户会觉得“跳过去也不知道该看哪里”。

Options

• 方案 A（最快修复）：issue report 里把 board 链接改为固定绝对地址 https://board.zondev.top（可加 from=diary 标识来源），只解决“能跳转”，不做数据联动。
• 方案 B（推荐联动）：实现“深链联动”——issue report 带 issueId/标签/日期范围跳到 board，board 自动过滤并提供回跳；代价是 board 需新增解析与过滤逻辑及路由约定。
• 方案 C（同源整合）：通过反向代理把 board 挂到同源路径（如 diary.zondev.top/board），统一 cookie/缓存策略与移动端样式复用；代价是运维与路由改造较大，但长期维护成本更低。
• 分支（另一种“board”定义）：若“board”其实指 GitHub Projects/Issues 看板，则应改链到 GitHub 项目看板并同步字段映射；与自建 board.zondev.top 的联动可降级为可选增强。

Evidence & Confidence

• 主张：链接失效与相对路径/basePath/缺协议有关；置信度：medium；理由：该类问题在子路径部署中最常见，但当前页面 HTML/代码与实际跳转无法在线核验。
• 主张：用环境变量/集中配置管理跨域入口能显著降低回归；置信度：high；理由：通用工程实践，与具体框架/部署细节无关。
• 主张：骨架屏+分段加载+懒加载/虚拟滚动能改善移动端卡顿；置信度：high；理由：直接降低首屏阻塞与渲染/内存压力，业界成熟可复用。
• 主张：做到“联动”需要 board 侧支持过滤/定位协议；置信度：medium；理由：取决于 board 当前是否已有筛选 API、路由设计与数据模型映射。

Next Steps

• 明确需求：board 入口是“全局看板”还是“按 issue 自动定位/过滤”；需要哪些参数（issueId、label、日期范围、returnUrl、from）。
• 技术确认：issue report 与 board 的技术栈、部署方式（同仓/分仓、是否有 basePath、CDN/反向代理规则），以及是否共享登录/数据源（GitHub Issues/自建 DB）。
• 实施热修：先用绝对 URL 修复跳转并加 e2e；随后按方案 B/C 做联动与移动端样式复用（抽公共组件/样式变量/设计 token）。
• 性能验收：移动端用 Lighthouse 与 Web Vitals 建基线（LCP/INP/CLS），逐项验证优化（代码分割、接口分页、缓存策略、骨架屏、延迟加载）效果并记录对比数据。

Sources

• Next.js 路由与链接：https://nextjs.org/docs/app/building-your-application/routing/linking-and-navigating （若非 Next.js，请忽略）
• Next.js Loading UI/Streaming 与懒加载：https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming ，https://nextjs.org/docs/app/building-your-application/optimizing/lazy-loading
• 性能指标与工具：https://web.dev/vitals/ ，https://developer.chrome.com/docs/lighthouse/overview ，https://developer.mozilla.org/en-US/docs/Web/Performance
• 数据请求与列表性能：SWR https://swr.vercel.app/ ，TanStack Query https://tanstack.com/query/latest ，react-window https://github.com/bvaughn/react-window；目标页面 https://diary.zondev.top/research/ 与 https://board.zondev.top 现状无法在线核验