用户目标

确认 TagLauncher 在“免费版 + Pro 解锁”首期中，是否需要把所有高级功能统一做成 V 图标锁定标识。

当前起点

• 已确认首期免费/Pro 功能边界与老用户自动 Pro 规则。
• 已收敛的设置页方案：
• Data 页放完整 Pro 状态区
• Theme 页放轻量镜像状态条
• 主题卡只保留小型 Pro / Preview 状态槽
• 风格约束：原生 macOS、克制、非营销化，不做付费墙式视觉。

讨论结论

不建议把所有高级功能统一挂 V 图标锁。

更合适的做法是分层表达：

• 页面级：Data 页 Pro 状态区承担主要权益说明
• 次级页：Theme 页轻量镜像提醒
• 对象级：主题卡等对象保留小型 Pro / Preview 状态槽
• 控件级：只有少量当前不可操作的具体入口，才使用轻量锁定态

关键原因

UI 视角

• V 不是天然的“锁定”语义，用户理解不如 Pro 文案或 lock 图标直接。
• 全局铺满 V 会让设置页更像付费墙，而不是系统设置。
• 会把页面级、卡片级、控件级三层状态混成一层，造成视觉噪音。

架构视角

• 全局 V 会额外引入一套新的权益可视化语义系统。
• 后续所有高级功能、主题、浅深色、hover/disabled 状态都要跟这套语义耦合，维护成本上升。

代码评审视角

• 真正复杂点不在“加图标”，而在一致性：位置、间距、颜色、禁用态、主题态、文案共存都会变成长期维护点。
• 现有 Pro / Preview / 锁定态 已足够表达，不需要再叠一层 V 体系。

QA 视角

• 全局 V 会显著扩大状态矩阵：免费/Pro、预览中/非预览、浅色/深色、多语种、可点击/禁用。
• 容易出现遗漏、错位、语义不一致，回归成本明显增加。

落地规则

后续实现按下面规则执行：

1. 不做全局 V 锁图标体系。
2. 需要表达付费权益时，优先使用 Pro 文本标识。
3. 需要表达“当前不可操作”时，才使用系统风格 lock + disabled 样式。
4. 不在分组标题、说明文案、整页所有高级项上重复挂标。

未决事项

• 如后续产品仍希望增强“高级功能识别度”，应单独讨论一版组件级标记规范，而不是直接上全局 V。