简介

Vue 3 引入了 Composition API，这是一种全新的组织组件逻辑的方式。相比 Options API，它提供了更好的代码组织能力和逻辑复用性。

核心概念

setup 函数

setup() 是 Composition API 的入口点，在组件创建之前执行：

import { ref, reactive, computed, onMounted } from 'vue'

export default {
  setup() {
    const count = ref(0)
    const user = reactive({
      name: 'CST',
      age: 25
    })

    const doubleCount = computed(() => count.value * 2)

    const increment = () => {
      count.value++
    }

    onMounted(() => {
      console.log('Component mounted!')
    })

    return {
      count,
      user,
      doubleCount,
      increment
    }
  }
}

ref vs reactive

生命周期钩子

Composition API 中的生命周期钩子以 on 前缀开头：

import {
  onMounted,
  onUpdated,
  onUnmounted,
  onBeforeMount,
  onBeforeUpdate,
  onBeforeUnmount
} from 'vue'

onMounted(() => {
  // 组件挂载后
})

onUnmounted(() => {
  // 组件卸载前
})

实战：自定义 Hook

// useCounter.ts
import { ref, computed } from 'vue'

export function useCounter(initialValue = 0) {
  const count = ref(initialValue)
  const doubled = computed(() => count.value * 2)

  const increment = () => count.value++
  const decrement = () => count.value--
  const reset = () => count.value = initialValue

  return {
    count,
    doubled,
    increment,
    decrement,
    reset
  }
}

总结

Composition API 让 Vue 3 的代码组织更加灵活，特别适合大型项目的开发。通过合理使用 ref、reactive、computed 等API，可以编写出更清晰、更可维护的代码。

为什么选择 Docker？

Docker 通过容器化技术，解决了"在我电脑上能运行"的经典问题。它提供了：

• 一致性：开发、测试、生产环境完全一致
• 轻量级：相比虚拟机，容器启动更快、资源占用更少
• 可移植：一次构建，到处运行

Dockerfile 优化

多阶段构建

# 构建阶段
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# 生产阶段
FROM node:20-alpine AS production
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/server.js"]

镜像层优化

# ❌ 不好 - 每次都会重新安装依赖
COPY . .
RUN npm install

# ✅ 好 - 利用缓存层
COPY package*.json ./
RUN npm install
COPY . .

Docker Compose 编排

version: '3.8'
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
      - DATABASE_URL=postgres://user:pass@db:5432/myapp
    depends_on:
      - db
      - redis

  db:
    image: postgres:16-alpine
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=myapp
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass

  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

安全最佳实践

1. 不要以 root 用户运行容器
2. 使用特定版本标签，避免 latest
3. 扫描镜像漏洞（使用 Trivy 或 Snyk）
4. 最小化镜像体积（使用 Alpine 基础镜像）
5. 不要在镜像中硬编码敏感信息

总结

掌握 Docker 的最佳实践，可以显著提升应用的部署效率和可靠性。

泛型基础

泛型是 TypeScript 最强大的特性之一，它允许我们编写灵活且类型安全的代码。

// 泛型函数
function identity<T>(arg: T): T {
  return arg
}

// 泛型接口
interface Repository<T> {
  findById(id: string): Promise<T | null>
  findAll(): Promise<T[]>
  create(data: Omit<T, 'id'>): Promise<T>
  update(id: string, data: Partial<T>): Promise<T>
  delete(id: string): Promise<void>
}

条件类型

type IsString<T> = T extends string ? true : false
type A = IsString<'hello'> // true
type B = IsString<42>      // false

// 内置条件类型
type Exclude<T, U> = T extends U ? never : T
type Extract<T, U> = T extends U ? T : never
type NonNullable<T> = T extends null | undefined ? never : T

映射类型

type Readonly<T> = {
  readonly [P in keyof T]: T[P]
}

type Partial<T> = {
  [P in keyof T]?: T[P]
}

// 实用工具类型
type Optional<T, K extends keyof T> = Omit<T, K> & Partial<Pick<T, K>>

模板字面量类型

type EventName = 'click' | 'focus' | 'blur'
type EventHandler = `on${Capitalize<EventName>}`
// 'onClick' | 'onFocus' | 'onBlur'

总结

TypeScript 的类型系统非常强大，合理使用高级类型可以让代码更加安全和可维护。

B+Tree 索引结构

MySQL InnoDB 引擎使用 B+Tree 作为默认索引结构。B+Tree 的特点是：

• 所有数据都存储在叶子节点
• 叶子节点通过指针相连，支持高效的范围查询
• 非叶子节点只存储索引键值，不存储数据

索引类型

主键索引（聚簇索引）

ALTER TABLE users ADD PRIMARY KEY (id);

唯一索引

CREATE UNIQUE INDEX uk_email ON users(email);

联合索引

CREATE INDEX idx_name_age ON users(name, age);

最左前缀原则

对于联合索引 idx(a, b, c)：

• WHERE a = 1 ✅ 使用索引
• WHERE a = 1 AND b = 2 ✅ 使用索引
• WHERE b = 2 ❌ 不使用索引
• WHERE a = 1 AND c = 3 ✅ 部分使用索引（只用a）

EXPLAIN 分析

EXPLAIN SELECT * FROM articles 
WHERE status = 'published' 
ORDER BY created_at DESC 
LIMIT 10;

关注以下字段：

• type: 访问类型（all > index > range > ref > eq_ref > const）
• key: 实际使用的索引
• rows: 预估扫描行数
• Extra: 额外信息（Using index, Using where 等）

总结

合理使用索引可以显著提升查询性能，但要注意避免过度索引。

什么是 Server Components？

React Server Components (RSC) 是 React 18+ 引入的新特性，允许组件在服务端渲染，减少客户端 JavaScript 体积。

核心优势

1. 零客户端体积：Server Components 的代码不会发送到客户端
2. 直接访问后端资源：可以直接访问数据库、文件系统
3. 自动代码分割：只有 Client Components 会被打包到客户端

基本用法

// app/articles/page.tsx (Server Component)
import { db } from '@/lib/db'

export default async function ArticlesPage() {
  const articles = await db.article.findMany({
    where: { status: 'published' },
    orderBy: { createdAt: 'desc' },
  })

  return (
    <div>
      {articles.map(article => (
        <ArticleCard key={article.id} article={article} />
      ))}
    </div>
  )
}

// ArticleCard 可以是 Client Component
'use client'
import { motion } from 'framer-motion'

export function ArticleCard({ article }) {
  return (
    <motion.div whileHover={{ scale: 1.02 }}>
      <h2>{article.title}</h2>
      <p>{article.excerpt}</p>
    </motion.div>
  )
}

数据获取模式

// 并行数据获取
async function getArticle(id: string) {
  const [article, comments] = await Promise.all([
    db.article.findUnique({ where: { id } }),
    db.comment.findMany({ where: { articleId: id } }),
  ])
  return { article, comments }
}

总结

React Server Components 代表了 React 未来的发展方向，合理使用可以大幅提升应用性能。

性能改进

.NET 10 在性能方面继续发力：

// 新的 Span-based API
ReadOnlySpan<char> text = "Hello, World!";
var index = text.IndexOfAny(' ', ',');

// 改进的 JSON 序列化
var options = new JsonSerializerOptions {
    DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull
};

新增 API

// 新的日期时间 API
var date = DateOnly.FromDateTime(DateTime.Now);

// 改进的 LINQ
var result = collection
    .OrderBy(x => x.Name)
    .Chunk(100)
    .Select((chunk, index) => new { Chunk = chunk, Index = index });

ASP.NET Core 改进

// 最小 API 增强
var app = WebApplication.Create(args);

app.MapGet("/api/articles", async (
    [FromServices] ArticleService service,
    [FromQuery] int page = 1,
    [FromQuery] int pageSize = 10
) => {
    var result = await service.GetPagedAsync(page, pageSize);
    return Results.Ok(result);
});

app.Run();

总结

.NET 10 继续在性能、开发体验和 API 设计方面取得进步，值得升级。

Git Flow vs GitHub Flow

Git Flow

适合有计划发布周期的项目：

• main - 生产代码
• develop - 开发分支
• feature/* - 功能分支
• release/* - 发布分支
• hotfix/* - 热修复分支

GitHub Flow

适合持续部署的项目：

# 1. 从 main 创建分支
git checkout -b feature/user-auth main

# 2. 开发并提交
git add .
git commit -m "feat: add user authentication"

# 3. 推送并创建 PR
git push origin feature/user-auth

# 4. Code Review 后合并
# 5. 删除分支

Commit 规范

<type>(<scope>): <subject>

type: feat, fix, docs, style, refactor, perf, test, chore

总结

选择合适的 Git 工作流，配合良好的 Commit 规范和 Code Review 流程，可以显著提升团队协作效率。

Prompt Engineering

基础技巧

角色：你是一个资深的前端开发工程师。

任务：请帮我优化以下 React 组件的性能。

要求：
1. 使用 React.memo 减少不必要的重渲染
2. 使用 useMemo 缓存计算结果
3. 使用 useCallback 缓存回调函数

代码如下：

Chain of Thought

引导模型逐步思考：

请一步一步地分析以下问题的解决方案：
1. 首先，理解问题的核心需求
2. 然后，列出可能的解决方案
3. 接着，比较各方案的优劣
4. 最后，给出推荐方案和实现代码

RAG (Retrieval-Augmented Generation)

RAG 将检索与生成结合，让 LLM 能够访问外部知识库：

// RAG 流程示例
async function ragQuery(question: string) {
  // 1. 将问题向量化
  const queryEmbedding = await embed(question)
  
  // 2. 检索相关文档
  const documents = await vectorStore.search(queryEmbedding, {
    topK: 5,
    threshold: 0.7
  })
  
  // 3. 构建增强 Prompt
  const context = documents.map(d => d.content).join('\n')
  const prompt = `基于以下上下文回答问题：\n\n${context}\n\n问题：${question}`
  
  // 4. 调用 LLM 生成回答
  return await llm.generate(prompt)
}

Agent 模式

interface Agent {
  name: string
  role: string
  tools: Tool[]
  execute(task: string): Promise<string>
}

// 多 Agent 协作
const team: Agent[] = [
  { name: 'Planner', role: '任务规划', tools: [] },
  { name: 'Coder', role: '代码编写', tools: [fileSystem, search] },
  { name: 'Reviewer', role: '代码审查', tools: [linter] },
]

总结

大语言模型正在改变软件开发的方式，掌握 LLM 应用开发将成为每个开发者的核心竞争力。

引言

在微服务架构中，服务之间的通信是系统设计的核心问题。与单体应用不同，微服务通过网络调用进行交互，这引入了延迟、可靠性、数据一致性等一系列挑战。本文将通过实际场景和可视化图表，帮助你理解并选择合适的通信模式。

同步通信：请求-响应模式

最基础的通信方式是同步的请求-响应模式。客户端发送请求后阻塞等待服务端返回结果。下面是一个典型的通过 API Gateway 访问微服务的时序图：

sequenceDiagram
    participant C as Client
    participant GW as API Gateway
    participant Auth as Auth Service
    participant User as User Service
    participant DB as Database

    C->>GW: HTTP Request
    GW->>Auth: Validate Token
    Auth-->>GW: Token Valid
    GW->>User: Forward Request
    User->>DB: Query Data
    DB-->>User: Return Data
    User-->>GW: Response
    GW-->>C: HTTP Response

这种模式简单直观，但存在级联失败的风险——如果某个下游服务不可用，整条调用链都会受影响。

异步通信：事件驱动模式

为了解耦服务间的依赖关系，我们通常采用基于消息队列的异步通信。服务不直接调用彼此，而是通过发布和订阅事件来协作：

flowchart LR
    A[订单服务] -->|OrderCreated| MQ[消息队列]
    MQ -->|OrderCreated| B[库存服务]
    MQ -->|OrderCreated| C[通知服务]
    MQ -->|OrderCreated| D[积分服务]
    B -->|StockReserved| MQ
    MQ -->|StockReserved| A

异步通信的优缺点

通信模式选择：决策流程

在实际项目中，我们往往不会只用一种模式，而是根据场景灵活选择。下面的流程图展示了一个实用的决策过程：

flowchart TD
    Start[需要服务间通信] --> Q{是否需要实时响应?}
    Q -->|是| Sync{调用链路是否超过 3 层?}
    Q -->|否| Async[使用消息队列异步通信]

    Sync -->|是| CQRS[考虑 CQRS + Event Sourcing]
    Sync -->|否| Direct[直接同步调用]

    Direct --> Retry[添加重试与熔断机制]
    CQRS --> EventBus[引入事件总线]
    Async --> DLQ[配置死信队列与重试策略]

    Retry --> Done[完成]
    EventBus --> Done
    DLQ --> Done

API Gateway 模式

API Gateway 是微服务架构的"门面"，它统一了外部客户端与服务内部之间的通信入口。核心职责包括：

1. 路由转发 — 将请求路由到正确的后端服务
2. 认证鉴权 — 统一处理 Token 校验、权限检查
3. 限流熔断 — 保护后端服务不被突发流量击垮
4. 协议转换 — 对外暴露 REST/gRPC，对内可使用任意协议

总结

微服务通信没有银弹，关键在于理解业务需求并选择合适的模式：

• 需要实时响应且链路短 → 同步 REST/gRPC
• 需要解耦和异步处理 → 消息队列事件驱动
• 调用链路复杂 → CQRS + Event Sourcing
• 统一入口和治理 → API Gateway

合理组合以上模式，才能构建出既灵活又可靠的微服务系统。