Global Cursor Rules (Frontend / JS)
Tech Stack
-
默认使用 现代 JavaScript (ES2019+ 或项目实际配置)，除非我明确要求 TypeScript。
-
不主动引入特定前端框架（如 Vue/React），优先使用 原生 JS + HTML/CSS。
-
如果当前项目已经采用框架或构建工具（如 React、Vue、Vite、Webpack），请 尊重并沿用现有技术栈和项目约定，不要强行更换。
Code Style
-
变量、函数：
camelCase；构造函数 / 类：PascalCase。 -
布尔值变量以
is/has/can/should开头，表达清晰语义。 -
尽量使用
const和let，不要再使用var。 -
优先使用模块化写法（
import/export），除非项目本身是老式 script 直接挂全局。 -
注释、说明文档：中文为主，必要时加英文术语，保持简短但说明清楚"为什么这样做"。
Project Structure
-
尊重当前项目目录结构，不随意新增顶层目录。
-
新增功能时，按项目现有风格拆分：例如
api/、utils/、components/、styles/等。 -
公共工具函数和常量提取到独立文件（如
utils/、constants/），避免在多个文件复制粘贴逻辑。
Context & Requirements
-
在编写或修改代码前，必须先阅读上下文：
-
查看当前文件顶部的注释、已有函数、引入模块。
-
如有相关文件（例如同名
*.css、utils、api），先快速浏览了解整体设计。
-
-
对于非特别简单的需求：
-
先根据我的描述 用列表列出实现步骤 / 设计思路。
-
确认步骤合理后，再根据这些步骤生成或修改代码。
-
-
不要只根据单一句话瞎写代码，要根据上下文推断真实需求；不明确的地方，给出合理假设并标明"假设点"。
Networking & State
-
发送网络请求时，优先复用项目现有的请求封装（如已有的
request、http、ajax模块），不要重复造轮子。 -
处理异步逻辑时优先使用
async/await，并在关键路径进行错误捕获（try/catch），给出友好错误处理接口（由调用方决定如何提示用户）。 -
全局状态或跨模块共享数据时，先查有没有现成的状态管理方案或全局对象；如无必要，不额外引入复杂状态管理库。
Editing Existing Code
-
修改现有代码时，优先进行最小变更，不要为了一点点需求重写整个文件。
-
保留原有结构、命名和注释风格，如需大改，请先用文字说明"改动范围和原因"，再给出完整新实现。
-
对于复杂逻辑：
-
先用伪代码或步骤列表解释算法/流程；
-
然后再给出实现代码。
-
-
避免引入破坏性改动（breaking changes），除非明确需要，并在注释中说明潜在影响。
Styles & Layout
-
当需求是"修改样式 / 布局"时：
-
只编辑 CSS / 样式相关部分 （独立 CSS 文件、
<style>块、内联样式），避免随意修改 JS 逻辑。 -
不改变现有 DOM 结构中的关键数据绑定或事件绑定，除非样式需求确实要求结构调整。
-
-
如果需要改动 HTML 结构来支持布局：
- 保证与原有 JS 逻辑兼容（事件、选择器、id/class 不要随意改名），如必须改名，请同步修改相关 JS，并在注释中说明。
-
样式命名遵循项目现有规范（如 BEM、utility class 等），不要混用多种风格。
Types & Tests (如果项目有)
-
如果项目已经使用 TypeScript 或 JSDoc 类型注解，请 沿用现有类型风格，不要随意删除类型。
-
新增工具函数时，如果项目已有测试体系（Jest/Vitest 等），尽量提供 1--2 个简单测试用例示例。
-
如果没有测试框架，则在注释中给出简单的使用示例和边界情况说明。
Interaction Style
-
回答默认使用简体中文，技术名词用英文原词。
-
对于非 trivial 的修改或新功能：
-
先简短说明思路 + 步骤列表；
-
再给出完整代码块。
-
-
遇到需求不完全明确时：
-
优先结合当前代码上下文做合理推断；
-
在答案中标注"假设 A/B/C"，避免频繁追问确认。
-
-
避免无关客套，内容聚焦在代码、设计思路和实现细节上。