应使用 实现字数目标输入框，设 min="1"、max="10000"、step="1"、required 并添加 aria-label；但必须后端校验，因前端可被绕过；localstorage 存取需严格类型转换；字数统计规则须前后端对齐。
怎么用 <input type="number"> 做字数目标输入框
直接用 <input type="number">，别用 text 再加 JS 校验——它原生支持最小值、最大值、步进和键盘限制，语义清晰，移动端还能唤出数字键盘。
常见错误是设了 min="0" 却忘了用户可能输负数或留空；或者用 pattern 强行套正则，反而破坏可访问性。
-
min设为"1"（不是"0"），避免无效目标 - 加上
required，防止提交空值 - 用
step="1"确保只接受整数（否则可能输入 1.5） - 给
id和aria-label，方便屏幕阅读器识别用途，比如aria-label="每日写作字数目标"
<input type="number" id="word-goal" name="word-goal" min="1" max="10000" step="1" required aria-label="每日写作字数目标">
为什么不能只靠前端验证字数目标
用户可以绕过任何 HTML 属性：禁用 JS、删掉 min、用 DevTools 直接修改 DOM，甚至 curl 提交非法值。后端必须重新校验。
典型翻车场景：前端设了 max="5000"，但后端没检查，结果存进数据库一个 999999，后续统计或提醒逻辑全崩。
- 后端收到值后，先转成整数，再判断是否在合理区间（如 1–10000）
- 注意类型转换陷阱：字符串
" 200 "或"200.0"可能被松散解析，建议用严格 parseInt + 显式检查 - 返回错误时，带上具体字段名（如
word-goal）和错误原因（如"字数目标必须是 1 到 10000 之间的整数"）
localStorage 保存目标值时的坑
用户关掉页面再打开，希望上次填的数字还在——这很合理，但 localStorage.setItem() 只接受字符串，直接存数字会隐式转字符串，读取时得手动转回数字，否则比较或计算会出错。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
更隐蔽的问题是：如果用户清空了输入框，input.value 是空字符串 ""，存进去再读出来就是 "", parseInt("") === NaN，后续逻辑可能静默失败。
- 写入前用
Number(input.value)转换，再检查是否为有效数字（!isNaN()且isFinite()） - 读取后同样做数字校验，无效时回退到默认值（如
500），别直接用NaN参与运算 - 别在
input的change事件里立刻存——用户还没输完就触发，容易存中间状态；改用blur或防抖后的input
怎么让目标值参与实时字数统计逻辑
用户输入笔记内容时，需要动态对比当前字数和目标值，但“字数”定义要统一：是字符数？中文字符数？还是去除空格/标点后的有效字数？HTML 本身不定义这个，得自己明确规则并前后端对齐。
常见混淆点：用 textarea.value.length 当“字数”，结果英文单词长、中文短，用户觉得不准；或者没处理换行符、全角空格，导致统计虚高。
- 如果按“中文字符+英文字母+数字”计数，可用正则
/[\u4e00-\u9fa5a-zA-Z0-9]/g匹配后取.length - 避免在每次
input事件里重复执行复杂正则——对长文本性能敏感，可节流或只在blur后算一次 - 对比时用
Math.min(current, target)计算进度百分比，别用current / target * 100——万一target是 0 或未设置，结果就炸了
前端能做的只是降低输入门槛和提供即时反馈，真正的约束在后端，真正的体验细节在字数定义是否一致。很多人卡在“看起来能跑”，却没想清楚“什么才算达成目标”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
