本文分享了一套个人前端编码规范与习惯。核心内容包括：文件命名规则（路由用kebab-case，组件用PascalCase，其他用camelCase）；推荐为复杂函数编写详细的JSDoc注释；代码风格上推崇函数式、RORO模式、TypeScript（接口优于类型，避免枚举）；并提出了性能优化建议，如优先使用RSC、Suspense、动态加载、优化图片和Web Vitals。
下面仅仅是我个人的自己收藏的一些规则以及自己写代码的习惯,并且随着时间的发展,ai 能力的提升可能越来越不适用,仅供参考
使用 kebab-case (例如: /app/user-profile, /app/product-catalog)。
原因: 这与 URL 路径的常见格式保持一致，并且是 Next.js App Router 中的自然选择。
使用 camelCase (例如: /src/lib/dataFetching.ts, /src/hooks/useAuth.ts, /src/utils/stringUtils.ts)。
原因: camelCase 是 JavaScript 和 TypeScript 世界中变量和函数的标准命名约定，用在这些辅助模块的文件名上也很自然。
使用 PascalCase (例如: /src/components/UserProfileCard.tsx, /src/components/ui/PrimaryButton.tsx)。
这是 React 社区的标准，清晰地标识出这些文件定义了 React 组件，并且与 JSX 中使用组件时的标签名 (<UserProfileCard />) 保持一致。
利用了不同场景下的约定俗成，并且通过大小写和分隔符的不同，在视觉上就能很好地区分出：
因为 ai 特别喜欢写如下不必要的代码,可以通过这个eslint 规则you-might-not-need-an-effect去避免
在许多项目中，开发者会创建一个 lib 或 utils 目录来存放共享的辅助代码。虽然两者有时可以互换使用，但进行区分有助于提升代码库的清晰度：
src/utils/: 推荐用于存放纯粹的、通用的、无副作用的辅助函数。这些函数通常不依赖于外部服务（如 API、数据库）或特定的框架特性，并且易于独立测试。formatDate.ts (日期格式化), stringUtils.ts (字符串操作), validationHelpers.ts (简单的同步校验函数), mathUtils.ts (计算工具)。src/lib/: 推荐用于存放更复杂的逻辑、与外部系统或框架集成的代码、核心业务逻辑封装、常量定义等。这些代码可能具有副作用，或者依赖于特定的环境或配置。lib/apiClient.ts (封装的 API 请求客户端), lib/auth.ts (认证相关逻辑，可能涉及 NextAuth 或其他库), lib/db.ts (数据库连接或 ORM 实例), lib/constants.ts (应用级常量), lib/hooks/useCustomHook.ts (共享的自定义 Hooks), lib/featureFlags.ts (功能开关逻辑)。区分的理由: 这种区分有助于开发者快速判断代码的性质和依赖程度。utils 目录下的代码通常是高度可移植和可复用的基础工具，而 lib 目录下的代码则更贴近应用的具体实现和外部依赖。
cursor 论坛流出的神级五大模式提问法,特别适合非 max 的模型使用,尤其是得益于 1M 容量的上下文长度,gemini 2.5 效果极佳,缺点就是会消耗更多的次数,相当于一个伪max 模式
