从名字开始：定位不清导致的命名失误#
回头来看，ENO MUSIC 可能并不是一个合适的对外名称。
eno对大多数用户来说没有明确语义，也不利于记忆music又容易让人误以为这是一个完整的音乐平台（如 Apple Music / QQ Music）
但实际上，这个项目的本质是：
- 一个 基于 bilibili API 的播放与管理工具
- 灵感来源于 YouTube Music
- 初衷是：避免为了听音乐而长期打开 B 站网页，占用大量内存资源
问题并不完全在名字本身，而在于：
项目在开发过程中，逐渐从 “工程工具” 向 “用户产品” 漂移，但命名和定位没有随之调整
如果一开始就明确这是一个面向普通用户的播放器，
名字或许更应该偏向功能直观型，例如 Bili Player、BB Player。
UI 问题：工程约束没有被坚持#
插件端与客户端的 UI 风格最终出现明显差异，并不是技术做不到，而是开发过程中没有始终坚持统一 UI 的工程约束。
- 两端并非同时开发
- 不同阶段的设计思路不同
- 在推进功能时，选择了 “先完成”，而不是 “保持统一抽象”
结果是：
- 功能基本一致
- 但使用体验差异明显
- 项目被拆成了两个 “感觉不同的产品”
如果当初坚持 只迭代同一套 UI 代码，
这个项目本可以沉淀出一套 可复用的 UI 组件体系，甚至演进为独立的组件库。
这是一次 短期效率优先于长期工程收益 的取舍失误。
播放列表与状态管理：做得最正确的一部分#
播放列表与状态管理是整个项目中最成功的工程设计。
- 插件端与客户端：
- 共享同一套 Pinia store
- 共享类型定义
- 共享播放控制逻辑（howler.js 的封装）
这一设计让客户端的初始版本几乎可以无缝迁移完成。
这验证了一点：
只要数据模型和核心逻辑足够稳定，UI 形态的变化成本是可控的
这是后续所有跨端项目中值得复用的模式。
下一步计划#
下一阶段的重点不在新增功能，而在工程收敛：
- 将客户端已经沉淀下来的 UI 组件迁移回插件端
- 让两个端在视觉与交互层面完全一致
- 重新对齐最初 “统一封装、统一体验” 的工程目标