最稳妥方式是用 ul + li 渲染协作邀请列表，服务端返回明确字段（inviter_name、invite_time_iso、invite_time_relative 等），前端用 map() 生成带按钮的 li，fetch 需设 credentials: 'include' 并检查 response.ok，按钮须满足 iOS 最小触控尺寸（min-width/min-height: 44px）并加 padding，避免 XSS 和重复提交。

HTML里怎么渲染待接受的协作邀请列表

直接用 ul + li 渲染最稳妥，别试图用 table 或自定义标签模拟表格结构——语义错、屏幕阅读器不友好、后续加「撤回」按钮也容易错位。

常见错误是把邀请数据塞进 data-* 属性再用 JS 拼 HTML 字符串，结果 XSS 风险高、更新成本大、服务端无法直出 SEO 友好内容。

• 服务端吐 JSON 数据时，确保字段明确：inviter_name、invite_time、project_name、invite_id
• 前端用 fetch 拿到后，用 map() 生成 li 元素，每个 li 包含一个 button（类型为 button，不是 submit）用于「接受」
• 拒绝操作建议走独立 API，不要复用同一个按钮的 toggle 状态，避免状态同步错乱

点击「接受」后页面没反应？检查 fetch 的 credentials 和响应处理

协作邀请接口通常要求带 Cookie 登录态，但默认 fetch 不发凭证，会返回 401 或空数组。

另一个高频坑：后端返回成功但没清掉当前列表项，导致用户点两次、重复提交。

立即学习“前端免费学习笔记（深入）”；

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 发起请求必须加 { credentials: 'include' }，否则跨域场景下登录态丢失
• 响应体要检查 response.ok，别只看 status === 200 ——有些服务端对失败也返回 200 + 错误字段
• 成功后立即从 DOM 中移除对应 li，或设 disabled + 灰色文字，防止重复点击

「邀请时间」显示成“刚刚”“2小时前”需要前端算？别硬写逻辑

纯前端相对时间计算在时区、夏令时、系统时间不准时容易翻车，尤其 iOS Safari 对 Date.parse() 解析 ISO 时间支持不稳定。

更稳的做法是后端返回两个字段：invite_time_iso（ISO 格式字符串）和 invite_time_relative（如 “3分钟前”），前者供排序/筛选，后者供展示。

• 如果必须前端算，用 Intl.RelativeTimeFormat 而非手写 if-else，它自动适配语言和时区
• 避免用 new Date().getTime() - new Date(isoStr).getTime() 算毫秒差——不同设备系统时间可能差几秒，导致“刚刚”变成“-2秒前”
• 定时刷新（比如每 30 秒）相对时间时，记得用 setTimeout 而非 setInterval，防止多个定时器叠加

移动端点「接受」按钮太小，iOS 上经常点不中

默认 button 在 iOS Safari 下点击热区只有文字高度，手指一滑就失效，不是 bug，是规范行为。

解决方法简单但常被忽略：给按钮加最小尺寸约束和内边距，同时确保父容器没有 overflow: hidden 截断点击区域。

• 按钮至少设 min-width: 44px、min-height: 44px（iOS 触控最小推荐值）
• 加 padding: 8px 16px，比单纯调 font-size 更可靠
• 外层 li 加 line-height: 1.5 防止文字挤在一起，影响可读性

协作邀请这类操作一旦失败，用户不会重试三次，而是直接切到别的 Tab —— 所以按钮是否点得中、反馈是否及时、错误提示是否具体，比动画效果重要得多。