请帮我重构这个函数，将其拆分成多个小函数。

原始函数：
[函数代码]

问题：
- 函数太长（[行数]行）
- 包含[数字]个不同的逻辑

拆分建议：
[说出你想如何拆分]

要求：
- 保持原有功能完全不变
- 新函数应该有清晰的职责
- 函数名应该具有说明性
- 包括[语言]的实现

要求：
1. 使用pytest框架
2. 覆盖所有分支（VIP、regular、其他）
3. 覆盖边界情况（0、负数、大数)
4. 每个测试函数名称清晰
5. 包含参数化测试（多个输入）

生成：
1. 完整的测试代码
2. 测试覆盖率应该100%

请为我设计GraphQL API。

数据模型：
- User (id, name, email, posts)
- Post (id, title, content, author)

需要的查询：
1. 获取用户信息
2. 获取用户的所有文章
3. 获取文章及其作者

需要的mutations：
1. 创建用户
2. 创建文章
3. 更新文章

请提供：
1. Schema定义
2. Query和Mutation示例
3. 订阅示例（如果适用）

请为我设计缓存策略。

应用特点：
- 热数据：[说明]
- 更新频率：[频率]
- 一致性要求：[要求]

缓存候选数据：
1. [数据1]: 更新频率[频率], 访问频率[频率]
2. [数据2]: ...

需要考虑：
1. 缓存层次（内存、Redis、CDN）
2. 缓存更新策略（TTL、事件驱动、LRU）
3. 缓存穿透、击穿、雪崩防护
4. 数据一致性处理

请给出缓存设计方案。

为我的应用设计索引策略。

常见查询：
1. SELECT * FROM users WHERE email = ?
2. SELECT * FROM users WHERE status = ? ORDER BY created_at DESC
3. SELECT * FROM orders WHERE user_id = ? AND created_at > ?

表结构：
[表定义]

当前索引：
[已有的索引]

问题：
1. 现有索引是否够用？
2. 需要新增什么索引？
3. 有没有冗余索引？
4. 索引对INSERT/UPDATE性能的影响？

我正在设计一个API，需要确保安全。

需要考虑的安全问题：
1. 认证方式（什么是最安全的？）
2. 令牌过期（多长时间合适？）
3. CORS配置（怎样防止跨域攻击？）
4. 速率限制（怎样实现？）
5. HTTPS/TLS
6. 日志敏感信息

请提供：
1. API认证方案
2. 安全最佳实践
3. 代码示例

这是我们的产品需求，请补充成完整的用户故事。

需求原文：
"系统应该支持用户搜索"

请生成用户故事，格式为：
作为 [用户角色]，
我想 [用户目标]，
以便 [商业价值/好处]

对于"搜索"功能，请生成3-5个不同角色的用户故事，包括：
- 每个故事的验收标准（至少3个）
- 可能的例外情况或边界条件
- 优先级建议

示例：
作为 博客读者，
我想 用关键词搜索感兴趣的文章，
以便 快速找到我需要的内容

验收标准：
1. 可以按标题和内容搜索
2. 搜索结果按相关性排序
3. 搜索可以过滤日期范围

用户报告[功能]有bug，但我不清楚代码在哪里。

bug现象：[现象描述]

代码库结构：
[描述代码库如何组织的]

可能相关的文件：
[列出可能相关的文件或模块]

问题：
1. 这个功能的代码最可能在哪里？
2. 应该追踪哪个函数的调用链？
3. 怎样快速定位问题所在？

请帮我追踪bug的位置。

为我的数据访问层编写集成测试。

实体：
- User (id, name, email, created_at)
- Order (id, user_id, amount, status)

Repository需要测试：
1. save(User) - 保存用户
2. findById(long) - 查询用户
3. findByEmail(String) - 按邮箱查询
4. delete(User) - 删除用户
5. findUserOrders(long) - 查询用户订单

要求：
1. 使用[数据库]作为测试数据库
2. 每个测试前初始化数据
3. 测试成功和失败的场景
4. 验证外键关系

请提供：
1. 测试数据的初始化脚本
2. 完整的测试用例

要求：
1. Mock PaymentGateway和EmailService
2. 覆盖成功和失败的场景
3. 验证emailService.sendConfirmation被调用了一次
4. 验证在支付失败时不发送邮件

使用[Mockito/其他mocking库]实现。

请根据这些信息生成架构文档。

系统概述：
[系统的功能和目标]

主要组件：
1. [组件1]: [说明]
2. [组件2]: [说明]
3. ...

关键决策：
[列出关键的架构决策]

数据流：
[描述数据流向]

技术栈：
[使用的技术]

需要生成：
1. 架构概览（文字说明）
2. 架构图（ASCII或Mermaid）
3. 组件说明
4. 技术选择理由
5. 扩展性考虑

检查维度：
1. 命名约定（函数名、变量名是否清晰）
2. 格式化（缩进、空格、换行）
3. 文档（是否需要docstring）
4. 复杂度（函数功能是否单一）
5. Python风格（是否符合PEP8）

基于最佳实践，给出改进的版本。