OneTimeSecret 项目中的计划配置重构：从硬编码到静态 YAML

背景与问题分析

OneTimeSecret 作为一个秘密分享服务，长期以来一直采用硬编码的方式管理用户计划(plans)配置。这种传统做法虽然简单直接，但随着项目发展逐渐暴露出几个关键问题：

1. 系统能力与功能边界耦合：原有实现将系统能力与功能边界混合在一起，导致职责不清晰
2. 配置对象命名冲突：计划配置与核心配置中的plans对象存在命名冲突
3. 业务逻辑耦合：代码库直接使用customer.planid字段进行UI逻辑判断，限制了系统灵活性

解决方案设计

项目团队提出了一个全面的重构方案，主要包含以下几个关键改进点：

1. 配置分离原则

将原本混合在一起的配置拆分为两部分：

• 静态配置(capabilities)：定义系统的基础能力，如API访问、邮件功能等
• 可变配置(secret_options)：包含可动态调整的参数，如默认TTL、大小限制等

这种分离使得系统核心能力与运行时配置解耦，提高了系统的可维护性。

2. 配置结构优化

对原有配置结构进行了以下调整：

• 将原有的plans对象重命名为billing，避免命名冲突
• 简化用户类型为"anonymous"和"authenticated"两种基础分类
• 引入层级化的配置结构，提高可读性

3. 术语规范化

采用更准确的术语来描述系统功能，避免直接使用商业化术语，使配置更加面向技术实现而非商业模型。

技术实现细节

新的配置采用YAML格式，分为静态和可变两部分：

静态配置示例

capabilities:
  anonymous:
    api: true
    email: false
    custom_domains: false
  authenticated:
    api: true
    email: true
    custom_domains: false

可变配置示例

secret_options:
  anonymous:
    default_ttl: <%= ENV['DEFAULT_TTL'] || nil %>
    ttl_options: <%= (ENV['TTL_OPTIONS'] || nil) %>
  standard:
    default_ttl: null
    ttl_options: null
    size: null

迁移注意事项

对于现有安装环境，需要注意：

1. 部分环境变量将变为废弃状态
2. 系统会通过迁移自动创建etc/mutable.yaml文件
3. 初始加载时会使用环境变量值设置匿名用户配置
4. 后续所有变更必须通过数据库进行

未来扩展性

这种新的配置架构为系统带来了更好的扩展性：

1. 可以轻松支持A/B测试等灵活的功能部署
2. 便于引入团队级别或对象级别的细粒度权限控制
3. 配置变更不再需要代码部署，提高了运维效率

总结

OneTimeSecret 的这次配置重构从架构层面解决了长期存在的技术债务，通过合理的职责分离和配置规范化，为项目的长期健康发展奠定了坚实基础。这种从硬编码到声明式配置的转变，也是现代软件开发中配置管理的最佳实践。