# 项目配置与用户配置分离讨论

**日期**: 2026-04-10

## 背景

在实现 IMAP ID 命令功能时，需要在连接时发送客户端身份信息。这些信息（name、version、vendor）属于**应用开发配置**，而非用户运行时配置。

如果将这些信息放在用户配置文件中：
- 用户可以看到但不需要修改这些"隐藏"配置
- 暴露了应用内部实现细节
- 用户可能误修改导致功能异常

## 讨论内容

### 配置文件分离

| 配置文件 | 用途 | 位置 | 内容 |
|---------|------|------|------|
| **用户配置** | 运行时用户数据 | `~/.config/pop/config.yml` | 账户、邮箱服务、默认行为 |
| **项目配置** | 应用开发相关 | `config/project.go` | 客户端信息、需要 ID 命令的 provider 集合 |

### 用户配置示例

```yaml
from:
  account: work

defaults:
  encryption: ssl
  insecure: false

unsafe_html: false

accounts:
  - name: work
    email: foolsecret@163.com
    provider: "163"
    username: foolsecret@163.com
    password: xxx
    imap:
      host: imap.163.com
      port: 993
    smtp:
      host: smtp.163.com
      port: 465
```

### 项目配置示例 (config/project.go)

```go
var ProjectConfig = struct {
    Info                       Info
    ProvidersNeedingCheckID    map[string]bool
}{
    Info: Info{
        Name:    "pop",
        Version: "1.0",
        Vendor:  "charmbracelet",
    },
    ProvidersNeedingCheckID: map[string]bool{
        "163": true,
        "QQ":  true,
    },
}
```

### CheckID 覆盖机制

用户可以在账户级别覆盖 CheckID 行为：

```yaml
accounts:
  - name: work
    check_id: false  # 禁用该账户的 ID 命令发送
```

逻辑优先级：
1. 用户明确设置 `check_id: false` → 不发送
2. 用户明确设置 `check_id: true` → 发送
3. 未设置 → 使用项目配置的 `ProvidersNeedingCheckID` 判断

### 扩展场景

未来可以扩展项目配置：
- 环境变量控制
- 调试模式开关
- 不同 provider 的特殊处理

## 结论

项目配置与用户配置分离是合理的架构设计：
- 职责分离：开发者配置 vs 用户配置
- 安全性：隐藏实现细节
- 可维护性：修改项目配置不影响用户数据

## 待处理

- [ ] 实现 config/project.go
- [ ] 修改 config.go 移除敏感字段
- [ ] 修改 imap.go 添加 ID 命令逻辑
- [ ] 更新文档