feat: 初始化项目并添加多个功能组件

style: 调整UI组件样式和布局 docs: 更新README和添加文档内容 chore: 添加依赖项和配置文件 fix: 修复一些小问题和优化代码 perf: 优化性能相关代码 refactor: 重构部分组件结构 test: 添加测试相关文件 build: 更新构建配置 ci: 添加CI配置文件
2026-01-21 16:16:01 +08:00
commit 426e9e0210
89 changed files with 13447 additions and 0 deletions
--- a/content/api-design-principles.mdx
+++ b/content/api-design-principles.mdx
@@ -0,0 +1,33 @@
+---
+title: "REST API Design Principles That Stand the Test of Time"
+publishedAt: "2024-12-12"
+updatedAt: "2024-12-12"
+author: "John Doe"
+summary: "Learn how to design APIs that developers love to use and are easy to maintain."
+image: "https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=800&h=192&fit=crop"
+---
+
+# REST API Design Principles That Stand the Test of Time
+
+Great APIs feel boring in the best way: predictable, consistent, and easy to reason about. When the surface area is simple, teams ship faster and clients break less often.
+
+This is a lightweight checklist you can keep in mind while designing new endpoints or reviewing an existing API.
+
+## Core principles
+
+- Use clear, consistent **resource names** (think nouns).
+- Keep behavior aligned with **HTTP semantics** (read vs write).
+- Return **consistent response shapes** so clients don’t guess.
+- Prefer **sane defaults** with optional query parameters for filtering/sorting.
+
+## A simple checklist
+
+1. Pick stable resource paths (plural nouns are a common convention).
+2. Use a small set of status codes consistently.
+3. Document pagination and what “next/previous” means.
+4. Be explicit about authentication and authorization requirements.
+5. Add brief examples in docs for the “happy path” and common errors.
+
+## Wrap-up
+
+If you optimize for consistency first, your API will be easier to document, easier to test, and easier for others to adopt.
--- a/content/building-design-systems.mdx
+++ b/content/building-design-systems.mdx
@@ -0,0 +1,146 @@
+---
+title: "Building Scalable Design Systems with React and Tailwind"
+publishedAt: "2024-12-01"
+updatedAt: "2024-12-01"
+author: "John Doe"
+summary: "A comprehensive guide to creating maintainable design systems that scale with your team and product."
+image: "https://images.unsplash.com/photo-1558655146-9f40138edfeb?w=800&h=192&fit=crop"
+---
+
+Design systems are the backbone of consistent user interfaces. Here's how to build one that scales.
+
+## Why Design Systems Matter
+
+A well-crafted design system provides:
+
+- **Consistency** across all products
+- **Faster development** with reusable components
+- **Better collaboration** between designers and developers
+- **Reduced technical debt** over time
+
+## Core Principles
+
+### 1. Start with Tokens
+
+Design tokens are the atomic values of your system:
+
+```typescript title="tokens.ts"
+export const tokens = {
+  colors: {
+    primary: {
+      50: '#eff6ff',
+      500: '#3b82f6',
+      900: '#1e3a8a',
+    },
+    neutral: {
+      0: '#ffffff',
+      100: '#f5f5f5',
+      900: '#171717',
+    },
+  },
+  spacing: {
+    xs: '0.25rem',
+    sm: '0.5rem',
+    md: '1rem',
+    lg: '1.5rem',
+    xl: '2rem',
+  },
+  radii: {
+    sm: '0.25rem',
+    md: '0.5rem',
+    lg: '1rem',
+    full: '9999px',
+  },
+} as const;
+```
+
+### 2. Build Primitive Components
+
+Start with the basics:
+
+```tsx title="Button.tsx"
+import { cva, type VariantProps } from "class-variance-authority";
+
+const buttonVariants = cva(
+  "inline-flex items-center justify-center rounded-md font-medium transition-colors",
+  {
+    variants: {
+      variant: {
+        primary: "bg-primary text-white hover:bg-primary/90",
+        secondary: "bg-secondary text-secondary-foreground hover:bg-secondary/80",
+        ghost: "hover:bg-accent hover:text-accent-foreground",
+      },
+      size: {
+        sm: "h-8 px-3 text-sm",
+        md: "h-10 px-4",
+        lg: "h-12 px-6 text-lg",
+      },
+    },
+    defaultVariants: {
+      variant: "primary",
+      size: "md",
+    },
+  }
+);
+
+interface ButtonProps
+  extends React.ButtonHTMLAttributes<HTMLButtonElement>,
+    VariantProps<typeof buttonVariants> {}
+
+export function Button({ variant, size, className, ...props }: ButtonProps) {
+  return (
+    <button className={buttonVariants({ variant, size, className })} {...props} />
+  );
+}
+```
+
+## Component Composition
+
+Build complex components from primitives:
+
+| Level | Examples | Purpose |
+|-------|----------|---------|
+| Tokens | Colors, spacing, typography | Foundation |
+| Primitives | Button, Input, Badge | Building blocks |
+| Patterns | Card, Modal, Dropdown | Common UI patterns |
+| Templates | PageHeader, Sidebar | Layout structures |
+
+## Documentation is Key
+
+> "A design system without documentation is just a component library."
+
+Every component should include:
+
+1. **Usage examples** - Show common use cases
+2. **Props documentation** - Explain all options
+3. **Accessibility notes** - ARIA labels, keyboard nav
+4. **Do's and Don'ts** - Guide proper usage
+
+## Versioning Strategy
+
+```json title="package.json"
+{
+  "name": "@company/design-system",
+  "version": "2.1.0",
+  "peerDependencies": {
+    "react": "^18.0.0",
+    "tailwindcss": "^3.0.0"
+  }
+}
+```
+
+Use semantic versioning:
+- **Major**: Breaking changes
+- **Minor**: New features (backward compatible)
+- **Patch**: Bug fixes
+
+## Conclusion
+
+Building a design system is an investment that pays dividends in:
+
+- Developer productivity
+- Design consistency
+- User experience
+- Team collaboration
+
+Start small, iterate often, and document everything.
--- a/content/git-workflow-guide.mdx
+++ b/content/git-workflow-guide.mdx
@@ -0,0 +1,38 @@
+---
+title: "Git Workflow Guide: From Chaos to Clarity"
+publishedAt: "2024-12-10"
+updatedAt: "2024-12-10"
+author: "John Doe"
+summary: "Master Git workflows that keep your team productive and your codebase healthy."
+image: "https://images.unsplash.com/photo-1556075798-4825dfaaf498?w=800&h=192&fit=crop"
+---
+
+# Git Workflow Guide: From Chaos to Clarity
+
+Git is powerful, but teams usually struggle because they don’t agree on a few basics. A simple workflow keeps history readable, reviews focused, and releases less stressful.
+
+This is a lightweight guide you can adopt in a day and iterate on later.
+
+## A simple team workflow
+
+- Branch from `main` for every change.
+- Keep branches small and short-lived.
+- Open a pull request early and ask for review.
+- Merge back to `main` once tests pass.
+
+## Commit message tips
+
+- Start with a clear verb (“add”, “fix”, “remove”, “refactor”).
+- Keep the first line short and specific.
+- Prefer multiple small commits over one giant “WIP”.
+
+## PR checklist
+
+1. Explain what changed and why.
+2. Link the issue or describe the user impact.
+3. Add tests (or explain why not).
+4. Keep the diff small enough to review quickly.
+
+## Wrap-up
+
+The goal isn’t “perfect Git” — it’s fewer surprises and faster collaboration. Start simple, write down the rules, and improve them as your team grows.
--- a/content/nextjs-performance-tips.mdx
+++ b/content/nextjs-performance-tips.mdx
@@ -0,0 +1,56 @@
+---
+title: "10 Next.js Performance Tips for Production Apps"
+publishedAt: "2024-12-05"
+updatedAt: "2024-12-05"
+author: "John Doe"
+summary: "Practical optimization techniques to make your Next.js applications blazing fast in production."
+image: "https://images.unsplash.com/photo-1460925895917-afdab827c52f?w=800&h=192&fit=crop"
+---
+
+Performance isn't optional—it's a feature. Here are battle-tested tips for optimizing Next.js apps.
+
+# 2. Optimize Images
+
+Always use `next/image`
+
+```tsx
+import Image from 'next/image';
+
+export function Hero() {
+  return (
+    <Image
+      src="/hero.jpg"
+      alt="Hero image"
+      width={1200}
+      height={600}
+      priority // Load immediately for LCP
+      placeholder="blur"
+      blurDataURL="data:image/jpeg;base64,..."
+    />
+  );
+}
+```
+
+
+## 4. Implement Proper Caching
+
+| Strategy | Use Case | TTL |
+|----------|----------|-----|
+| `force-cache` | Static data | Forever |
+| `revalidate: 3600` | Semi-static | 1 hour |
+| `revalidate: 60` | Frequently updated | 1 minute |
+| `no-store` | Real-time data | Never cache |
+
+## 5. Minimize Client Components
+
+Every `'use client'` directive adds to your JavaScript bundle. Keep client components small and focused:
+
+## 6. Bundle Analysis
+
+```bash title="terminal"
+# Install analyzer
+npm install @next/bundle-analyzer
+
+# Run analysis
+ANALYZE=true npm run build
+```
--- a/content/remote-work-productivity.mdx
+++ b/content/remote-work-productivity.mdx
@@ -0,0 +1,43 @@
+---
+title: "Mastering Remote Work: Productivity Tips from a Digital Nomad"
+publishedAt: "2024-11-25"
+updatedAt: "2024-11-25"
+author: "John Doe"
+summary: "Practical strategies for staying productive, focused, and balanced while working remotely, based on years of experience."
+image: "https://images.unsplash.com/photo-1521791136064-7986c2920216?w=800&h=192&fit=crop"
+---
+
+# Mastering Remote Work: Productivity Tips
+
+Remote work is less about “working from anywhere” and more about building routines that protect your focus and your energy. A few small defaults go a long way.
+
+> Remote work works best when your day has clear starts, clear stops, and fewer context switches.
+
+## Common challenges
+
+- Home distractions
+- Blurry work/life boundaries
+- Fewer casual social touchpoints
+- Async communication gaps
+
+## Daily routine checklist (example)
+
+| Habit | Why it helps
+|------|--------------
+| Dedicated workspace | Signals "work mode"
+| Plan top 3 tasks | Reduces overwhelm
+| Deep work block | Protects focus
+| Walk / stretch break | Prevents burnout
+| Shutdown ritual | Creates a clear end
+
+## Tools (keep it minimal)
+
+- [x] Pick one task tracker (e.g. Linear / GitHub Issues)
+- [ ] Pick one notes app (e.g. Notion / Obsidian)
+- [ ] Keep a single calendar (e.g. Google Calendar)
+- [ ] Turn on Focus / Do Not Disturb during deep work
+- [ ] Prefer async updates; use chat for blockers only
+
+## Wrap-up
+
+Start with one routine change (workspace + “top 3 tasks”) and one boundary (a daily shutdown time). Once those stick, iterate.
--- a/content/testing-react-apps.mdx
+++ b/content/testing-react-apps.mdx
@@ -0,0 +1,36 @@
+---
+title: "Testing React Applications: A Practical Guide"
+publishedAt: "2024-12-14"
+updatedAt: "2024-12-14"
+author: "John Doe"
+summary: "From unit tests to E2E—learn how to build confidence in your React applications with comprehensive testing."
+image: "https://images.unsplash.com/photo-1516116216624-53e697fedbea?w=800&h=192&fit=crop"
+---
+
+# Testing React Applications: A Practical Guide
+
+Tests are your safety net — they let you refactor with confidence and ship changes without fear. The goal is not “as many tests as possible”; it’s <mark>confidence in the critical paths</mark>.
+
+If your test suite feels slow or fragile, it usually means you’re testing the wrong thing. In practice, you can ignore a lot of “perfect coverage” advice and focus on a few high-signal habits.
+
+## What to test (a simple rule)
+
+- **Unit tests**: small, fast checks for logic and pure functions.
+- **Integration tests**: components + data + user flows (most value per test).
+- **E2E tests**: a few happy-path checks across the whole app.
+
+## High-signal testing habits
+
+- Prefer user-facing assertions (what the user sees/does).
+- Use accessible queries first (roles, labels).
+- Mock at the boundary (network) instead of mocking implementation details.
+
+## Things to avoid
+
+- ~~Testing internal component state~~ when behavior is what matters.
+- ~~Sprinkling test IDs everywhere~~ as a first choice.
+- Overusing snapshots that fail for harmless UI changes.
+
+## Wrap-up
+
+Start small: one integration test for your most important flow, then add unit tests for tricky logic. Over time, your tests become living documentation that helps you move faster.
--- a/content/typescript-best-practices.mdx
+++ b/content/typescript-best-practices.mdx
@@ -0,0 +1,41 @@
+---
+title: "TypeScript Best Practices for Clean, Maintainable Code"
+publishedAt: "2024-12-08"
+updatedAt: "2024-12-08"
+author: "John Doe"
+summary: "Essential TypeScript patterns and practices that will make your codebase more robust and easier to maintain."
+image: "https://images.unsplash.com/photo-1555066931-4365d14bab8c?w=800&h=192&fit=crop"
+---
+
+# TypeScript Best Practices for Clean, Maintainable Code
+
+TypeScript shines when it helps you model reality — not when it forces you to fight types all day. A few small defaults can make a codebase feel <mark>calmer, safer, and easier to refactor</mark>.
+
+<MediaContainer
+  src="https://images.unsplash.com/photo-1555066931-4365d14bab8c?w=1200&fit=crop"
+  alt="TypeScript code on screen"
+/>
+
+## Practical rules of thumb
+
+- Turn on strictness and fix the sharp edges early.
+- Prefer readable types over clever types.
+- Use unions for “one of these”, interfaces for “shape of this”.
+- Avoid `any` as a shortcut; it becomes ~~future debt~~ fast.
+
+## One pattern worth memorizing
+
+```ts
+type Result<T> =
+  | { ok: true; value: T }
+  | { ok: false; error: string };
+
+export function parseNumber(input: string): Result<number> {
+  const n = Number(input);
+  return Number.isFinite(n) ? { ok: true, value: n } : { ok: false, error: "Not a number" };
+}
+```
+
+## Wrap-up
+
+The best TypeScript code reads like good documentation: clear names, predictable shapes, and errors that point you to the fix.