componentDidMount() {
this.fetchUsers();
this.unsubscribe = this.props.store.subscribe(() => {
this.setState({ users: this.props.store.getState().users });
});
}

componentDidUpdate(prevProps) {
// 这里有个隐藏bug：当filter变化时，会重复订阅
if (prevProps.filter !== this.props.filter) {
this.fetchUsers();
}
}

componentWillUnmount() {
if (this.unsubscribe) {
this.unsubscribe();
}
}

这个设计真的反人类。componentDidUpdate里改了filter就重新fetch，但subscribe还在，导致内存泄漏。我让Claude Code重构：

提示词："将UserList类组件重写为函数组件，使用useEffect和useState，注意修复订阅泄漏和重复请求问题。"

Claude Code返回的代码让我眼前一亮：

// 数据获取逻辑
useEffect(() => {
let cancelled = false;
setLoading(true);

fetchUsers(filter).then(data => {
if (!cancelled) {
setUsers(data);
setLoading(false);
}
}).catch(err => {
if (!cancelled) {
setError(err);
setLoading(false);
}
});

return () => { cancelled = true; };
}, [filter]);

// Store订阅逻辑
useEffect(() => {
const unsubscribe = store.subscribe(() => {
setUsers(store.getState().users);
});
return unsubscribe;
}, [store]);

另一个坑：Claude Code可能因为上下文长度限制，只重写了核心逻辑，忽略了样式文件和测试用例。这时候你得主动问："请生成对应的测试用例"。

场景二：数据库迁移的翻车现场

然后是数据库迁移。原来的MySQL表是2018年设计的，没有外键，没有索引，查询一个用户详情要JOIN 5张表，耗时 12秒。老板忍了三年。

我让Claude Code生成迁移脚本：

提示词："分析这个MySQL表的慢查询，生成添加索引和外键的迁移脚本，要求：1）不影响现有数据 2）支持回滚 3）分批次执行"

Claude Code给的脚本很规范：

-- Step 1: 添加用户表索引
ALTER TABLE users ADD INDEX idx_users_email (email);
ALTER TABLE users ADD INDEX idx_users_status_created (status, created_at);

-- Step 2: 添加订单表索引
ALTER TABLE orders ADD INDEX idx_orders_user_id (user_id);
ALTER TABLE orders ADD INDEX idx_orders_status_date (status, order_date);

-- Step 3: 添加外键（用ALTER IGNORE防止已有脏数据）
ALTER TABLE orders ADD CONSTRAINT fk_orders_user
FOREIGN KEY (user_id) REFERENCES users(id)
ON DELETE CASCADE;

但执行时出问题了：订单表里有 4000多条 脏数据（user_id指向不存在的用户），导致外键添加失败。Claude Code的脚本没考虑到这一点。

官方文档这段文档不够清晰：它说"ALTER TABLE时如果数据不一致会失败"，但没告诉你怎么办。

我的解决方案：先清理脏数据，再执行迁移。让Claude Code生成清理脚本：

-- 删除脏数据（先备份到temp表）
CREATE TABLE orders_backup_202401 AS
SELECT * FROM orders
WHERE user_id NOT IN (SELECT id FROM users);

DELETE FROM orders
WHERE user_id NOT IN (SELECT id FROM users);

执行后，查询时间从 12秒 降到了 0.3秒。老板说："嗯，看起来还行。"（老板永远不说"很好"）。

还有个技巧：让Claude Code生成一个性能对比报告，直接发给老板看，省得你解释。

核心部分：迁移前后的MySQL查询性能对比柱状图，左侧12秒，右侧0.3秒，标注了索引和清理操作

场景三：前端与数据库的联调重构

前端重构完，数据库迁移完，但两者联调时出了问题。原来的API返回的是嵌套JSON（深度5层），前端组件直接消费。重构后前端用了GraphQL风格的数据扁平化，但后端没改。

Claude Code帮了大忙：我让它分析API和前端的数据依赖，生成一个中间层（BFF）脚本。

提示词："分析这两个文件：1）旧的API返回格式 2）新的前端组件数据需求。生成一个Node.js中间层，把旧API格式转换成新格式。"

Claude Code生成的转换函数：

实战总结：你可以立刻用的三个点