Expensify/App 免费试用期结束后仍可执行计费操作的技术分析与解决方案

在 Expensify/App 项目中，我们发现了一个关于订阅计费逻辑的边界条件问题。当工作区的免费试用期结束后，用户理论上不应再执行任何会产生费用的操作，但实际测试表明，某些操作路径仍可绕过这一限制。

问题现象

当用户处于已结束试用期的工作区时，系统存在两种添加费用的方式：

1. 通过文本输入框旁的"+"按钮添加费用（系统会正确阻止并显示试用期结束提示）
2. 通过页面顶部的"添加费用"主操作按钮（可绕过限制成功创建费用）

这种不一致的行为会导致潜在的收入损失和用户体验问题。

技术分析

经过代码审查，我们发现问题的根源在于：

1. 组件间状态检查不一致：ReportActionCompose组件（负责"+"按钮）正确实现了PolicyUtils.isWorkspaceExpired检查，而HeaderWithBackButton/MoneyReportHeader组件（负责顶部按钮）缺少相同验证。

2. 策略工具类未充分利用：现有的PolicyUtils类已包含isTrialExpired等关键方法，但未被所有相关组件调用。

3. 导航逻辑不统一：当操作被阻止时，系统应统一重定向至订阅页面，但部分路径未实现这一行为。

解决方案实现

我们采用了多层次防御策略来解决这个问题：

1. 增强策略检查：

const isExpired = PolicyUtils.isWorkspaceExpired(policy);

2. 统一拦截逻辑：

• 对于顶部操作按钮，添加与内联按钮相同的状态检查
• 当检测到过期时，重定向至订阅页面：

Navigation.navigate(ROUTES.getWorkspaceBillingPage(policy.id));

3. 完善策略工具： 扩展PolicyUtils类，确保所有组件使用相同的过期判断标准：

isWorkspaceExpired(policy) {
    return policy?.isArchived || policy?.isTrialExpired;
}

测试验证方案

为确保修复质量，我们设计了跨平台的测试用例：

1. 基础场景测试：

• 使用已过期试用期的工作区
• 验证两种添加费用途径都被正确拦截
• 确认重定向至订阅页面

2. 边界条件测试：

• 试用期未结束的工作区（应允许操作）
• 已订阅的工作区（应允许操作）
• 已归档的工作区（应阻止操作）

3. 多平台验证：

• Web端（Chrome/Safari/Firefox）
• 移动端（iOS/Android原生应用）
• 响应式布局适配

经验总结

这个案例为我们提供了几个重要的技术启示：

1. 状态管理一致性：对于关键业务规则（如订阅状态），应通过统一的服务/工具类集中管理，避免分散实现。

2. 防御性编程：在涉及收入相关的功能点上，需要采用多层验证机制。

3. 组件化思维：共享功能应抽象为可复用组件，减少重复实现带来的不一致风险。

4. 端到端测试：支付流程等关键路径需要完整的场景测试覆盖，包括正向和负向用例。

通过这次修复，我们不仅解决了具体问题，还完善了项目的订阅状态管理体系，为后续类似功能的开发建立了更可靠的模式。