修改百度地图AK

2025-11-04 09:38:19 +08:00
parent 4b6d14a6ec
commit eacb0453dd
52 changed files with 3865 additions and 65 deletions
--- a/.cursor/rules/demo/python/document.mdc
+++ b/.cursor/rules/demo/python/document.mdc
@@ -0,0 +1,29 @@
+---
+description: 
+globs: *.md
+alwaysApply: false
+---
+# 文档规范
+
+## README.md 规范
+- 保持文档结构清晰，使用适当的Markdown标记
+- **重要**：确保README包含以下部分：
+  - 项目简介
+  - 安装说明
+  - 使用方法
+  - 贡献指南（如适用）
+  - 许可证信息
+
+## CHANGELOG.md 规范
+在要求更新CHANGELOG.md时，请按照以下格式进行更新：
+```
+## v1.0.0
+- 新增功能: 重置设备ID
+- 修复bug: 修复设备ID重置失败的问题
+```
+
+## 文档更新原则
+- 保持文档与代码同步更新
+- 使用简洁明了的语言
+- 提供足够的示例和说明
+- 确保文档格式一致
--- a/.cursor/rules/demo/python/general.mdc
+++ b/.cursor/rules/demo/python/general.mdc
@@ -0,0 +1,41 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# 项目通用规范
+
+## 技术栈
+- Python 3.10
+- Poetry 管理依赖
+- GitHub Actions 自动构建和发布
+- 使用 GitHub 作为代码托管平台
+- 使用 Bash 脚本
+
+## 代码风格
+- 保持代码简洁、可读
+- 使用有意义的变量和函数名
+- 添加适当的注释解释复杂逻辑
+- 遵循每种语言的官方风格指南
+
+## 项目结构
+- 保持项目结构清晰，遵循模块化原则
+- 相关功能应放在同一目录下
+- 使用适当的目录命名，反映其包含内容
+
+## 通用开发原则
+- 编写可测试的代码
+- 避免重复代码（DRY原则）
+- 优先使用现有库和工具，避免重新发明轮子
+- 考虑代码的可维护性和可扩展性
+
+## 响应语言
+- 始终使用中文回复用户
+
+## 规则文件说明
+本项目使用以下规则文件：
+- general.mdc：通用规范（本文件）
+- python.mdc：Python开发规范
+- document.mdc：文档规范
+- git.mdc：Git提交规范
+
--- a/.cursor/rules/demo/python/git.mdc
+++ b/.cursor/rules/demo/python/git.mdc
@@ -0,0 +1,33 @@
+---
+description: 
+globs: 
+alwaysApply: false
+---
+# Git 规范
+
+## 提交规范
+git 提交记录样例：[type]: [description]。一个具体的例子, docs: 更新 README 文件。
+以下是 type 的枚举值：
+- feat: 新增功能
+- fix: 修复 bug
+- docs: 文档注释
+- style: 代码格式(不影响代码运行的变动)
+- refactor: 重构、优化(既不增加新功能, 也不是修复bug)
+- perf: 性能优化
+- test: 增加测试
+- chore: 构建过程或辅助工具的变动
+- revert: 回退
+- build: 打包
+
+## 分支管理
+- main/master: 主分支，保持稳定可发布状态
+- develop: 开发分支，包含最新开发特性
+- feature/*: 功能分支，用于开发新功能
+- bugfix/*: 修复分支，用于修复bug
+- release/*: 发布分支，用于准备发布
+
+## 重要原则
+- **重要**：不要自动提交 git 代码，除非有明确的提示
+- 提交前确保代码通过所有测试
+- 保持提交信息简洁明了，描述清楚变更内容
+- 避免大型提交，尽量将变更分解为小的、相关的提交
--- a/.cursor/rules/demo/python/python.mdc
+++ b/.cursor/rules/demo/python/python.mdc
@@ -0,0 +1,30 @@
+---
+description: 编写 python 文件
+globs: *.py
+alwaysApply: false
+---
+# 角色
+你是一名精通Python的高级工程师，拥有20年的软件开发经验。
+
+# 目标
+你的目标是以用户容易理解的方式帮助他们完成Python项目的设计和开发工作。你应该主动完成所有工作，而不是等待用户多次推动你。
+
+你应始终遵循以下原则：
+
+### 编写代码时：
+- 遵循PEP 8 Python代码风格指南。
+- 使用Python 3.10 及以上的语法特性和最佳实践。
+- 合理使用面向对象编程(OOP)和函数式编程范式。
+- 利用Python的标准库和生态系统中的优质第三方库。
+- 实现模块化设计，确保代码的可重用性和可维护性。
+- 使用类型提示(Type Hints)进行类型检查，提高代码质量。
+- 编写详细的文档字符串(docstring)和注释。
+- 实现适当的错误处理和日志记录。
+- 按需编写单元测试确保代码质量。
+
+### 解决问题时：
+- 全面阅读相关代码文件，理解所有代码的功能和逻辑。
+- 分析导致错误的原因，提出解决问题的思路。
+- 与用户进行多次交互，根据反馈调整解决方案。
+
+在整个过程中，始终参考@Python官方文档，确保使用最新的Python开发最佳实践。
--- a/.cursor/rules/demo/vue/document.mdc
+++ b/.cursor/rules/demo/vue/document.mdc
@@ -0,0 +1,68 @@
+---
+description: 
+globs: *.md
+alwaysApply: false
+---
+# 文档规范
+
+## 通用要求
+- 所有文档使用Markdown格式
+- 使用简洁、清晰的语言
+- 文档内容应保持最新
+- 避免拼写和语法错误
+- 使用中文作为主要语言
+
+## 目录结构
+- `README.md`：项目根目录，提供项目概述
+- `docs/`：存放详细文档
+  - `guide/`：使用指南
+  - `api/`：API文档
+  - `examples/`：示例代码文档
+
+## README.md 内容规范
+- 项目名称和简短描述
+- 技术栈说明
+- 项目结构说明
+- 安装与运行指南
+- 基本使用示例
+- 贡献指南链接
+- 许可证信息
+
+## Markdown 格式规范
+- 使用 ATX 风格的标题（使用 # 符号）
+- 标题层级不应跳跃（如 h1 后面直接使用 h3）
+- 代码块需指定语言类型
+- 列表项使用 - 而非 * 或 +
+- 链接使用 [文本](mdc:URL) 格式
+- 图片使用 ![替代文本](mdc:图片URL) 格式
+
+## 文档内容组织
+- 从整体到局部，从简单到复杂
+- 重要信息放在前面
+- 相关内容应当放在一起
+- 使用小标题和列表增强可读性
+- 避免过长段落，保持内容简洁
+
+## 代码示例规范
+- 提供完整可运行的示例
+- 代码应当简洁且易于理解
+- 添加适当的注释解释关键部分
+- 说明代码的预期输出或行为
+- 更新示例以匹配最新API
+
+## 版本记录规范
+- 使用 `CHANGELOG.md` 记录版本变更
+- 遵循语义化版本（Semantic Versioning）规范
+- 每个版本应包含：新增功能、修复问题、破坏性变更
+
+## 图表与图片
+- 使用清晰、分辨率足够的图片
+- 为图片提供有意义的替代文本
+- 图表应当简洁，避免过多装饰
+- 图表颜色应当考虑色盲用户的可访问性
+
+## 文档审核
+- 新文档应经过至少一人审核
+- 定期检查文档的准确性和时效性
+- 鼓励用户反馈文档问题
+- 修复发现的文档错误应当优先处理
--- a/.cursor/rules/demo/vue/general.mdc
+++ b/.cursor/rules/demo/vue/general.mdc
@@ -0,0 +1,40 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# 项目通用规范
+
+## 技术栈
+- Vue 3 
+- Vite 前端构建工具
+- Vue Router 路由管理
+- Pinia 状态管理
+
+## 代码风格
+- 保持代码简洁、可读
+- 使用有意义的变量和函数名
+- 添加适当的注释解释复杂逻辑
+- 遵循Vue语言的官方风格指南
+
+## 项目结构
+- 保持项目结构清晰，遵循模块化原则
+- 相关功能应放在同一目录下
+- 使用适当的目录命名，反映其包含内容
+
+## 通用开发原则
+- 编写可测试的代码
+- 避免重复代码（DRY原则）
+- 优先使用现有库和工具，避免重新发明轮子
+- 考虑代码的可维护性和可扩展性
+
+## 响应语言
+- 始终使用中文回复用户
+
+## 本项目规则文件说明
+本项目使用以下规则文件：
+- general.mdc：通用规范（本文件）
+- document.mdc：文档规范
+- git.mdc：Git提交规范
+- xxx.mdc：XXX 语言开发规范
+
--- a/.cursor/rules/demo/vue/git.mdc
+++ b/.cursor/rules/demo/vue/git.mdc
@@ -0,0 +1,52 @@
+---
+description: 辅助生成 git 提交信息
+globs: 
+alwaysApply: false
+---
+# Git 规范
+
+## 提交规范
+git 提交模板<type>(<scope>): <subject>，具体要求如下：
+1. 注意冒号 : 后有空格
+2. type 的枚举值有：
+- feat: 新增功能
+- fix: 修复 bug
+- docs: 文档注释
+- style: 代码格式(不影响代码运行的变动)
+- refactor: 重构、优化(既不增加新功能, 也不是修复bug)
+- perf: 性能优化
+- test: 增加测试
+- chore: 构建过程或辅助工具的变动
+- revert: 回退
+- build: 打包
+3. 若 subject 中描述超过两种要点，请使用要点列表描述详情，每个要点使用-符号开头，多个换行，参考如下样例：
+```
+feat(web): implement email verification workflow
+
+- Add email verification token generation service
+- Create verification email template with dynamic links
+- Add API endpoint for token validation
+- Update user model with verification status field
+```
+
+## 分支管理
+- main/master: 主分支，保持稳定可发布状态
+- develop: 开发分支，包含最新开发特性
+- feature/*: 功能分支，用于开发新功能
+- bugfix/*: 修复分支，用于修复bug
+- release/*: 发布分支，用于准备发布
+
+**常用分支命名约定**：
+
+| 分支类型   | 命名格式             | 示例                      |
+| ---------- | -------------------- | ------------------------- |
+| 功能分支   | feature/[描述]       | feature/user-auth         |
+| 修复分支   | fix/[问题ID]-[描述]  | fix/issue-42-login-crash  |
+| 发布分支   | release/[版本]       | release/v2.1.0            |
+| 热修复分支 | hotfix/[版本]-[描述] | hotfix/v2.0.1-payment-fix |
+
+## 重要原则
+- **重要**：不要自动提交 git 代码，除非有明确的提示
+- 提交前确保代码通过所有测试
+- 保持提交信息简洁明了，描述清楚变更内容
+- 避免大型提交，尽量将变更分解为小的、相关的提交
--- a/.cursor/rules/demo/vue/vue.mdc
+++ b/.cursor/rules/demo/vue/vue.mdc
@@ -0,0 +1,68 @@
+---
+description: 
+globs: *.vue
+alwaysApply: false
+---
+# Vue 开发规范
+
+## 组件命名
+- 组件名应该始终使用多词组合，避免与HTML元素冲突
+- 使用PascalCase命名组件：`TodoItem.vue`、`UserProfile.vue`
+- 基础组件应使用特定前缀，如`Base`、`App`或`V`
+- 组件名应该是描述性的，不要过于简略
+
+## 组件结构
+- 使用`<script setup>`语法糖
+- 使用组合式API (Composition API)
+- 组件选项/属性顺序：
+  1. name
+  2. components
+  3. props
+  4. emits
+  5. setup()
+  6. data()
+  7. computed
+  8. methods
+  9. 生命周期钩子
+- 使用单文件组件(SFC)格式
+
+## Props 规范
+- Prop名使用camelCase
+- Prop需要定义类型和默认值
+- 避免使用数组或对象的默认值，应该使用工厂函数返回默认值
+- Prop应该尽可能详细地定义，包括类型、是否必须和验证函数
+
+## 事件命名
+- 事件名应使用kebab-case，如`item-click`、`menu-select`
+- 自定义事件应该有明确的含义，表示发生了什么
+- 避免使用容易混淆的事件名称
+
+## 样式指南
+- 优先使用scoped CSS
+- 避免使用!important
+- 组件特定样式应该有特定的前缀
+- 考虑使用CSS变量实现主题
+
+## 性能优化
+- 使用`v-show`代替`v-if`进行频繁切换
+- 长列表使用虚拟滚动
+- 避免在计算属性中进行复杂操作
+- 使用keep-alive缓存组件
+- 合理使用异步组件和懒加载
+
+## 状态管理
+- 使用Pinia进行状态管理
+- store应该按功能模块划分
+- 保持store简单，避免过度设计
+
+## 路由
+- 路由名称应当与组件名称匹配
+- 使用懒加载减少初始加载时间
+- 路由守卫应当简洁，避免复杂逻辑
+
+## 通用建议
+- 避免使用`this.$parent`或`this.$refs`直接操作DOM
+- 优先使用计算属性而不是复杂的模板表达式
+- 使用v-for时必须提供key
+- 不要在同一元素上同时使用v-if和v-for
+- 复用组件时使用key确保完全重新渲染