.fam 如何在一开始填充表型与性别

对于 PLINK 的 --logistic 来说，1=Control、2=Case 是约定俗成且推荐的编码方式。如果把它们反过来，会影响回归结果的解释（特别是 OR 的方向），但不会改变显著性（P 值）。

1. 推荐编码

Control -> 1
Case    -> 2

例如：

PLINK 会把 2 视为事件（Case），模型可以理解为：

logit(P(Case)) = β0 + β1 × SNP + ...

此时：

• OR > 1：等位基因增加患病风险。
• OR < 1：等位基因具有保护作用。

2. 如果反过来写

假设写成：

Control -> 2
Case    -> 1

那么模型实际上变成：

logit(P(Control)) = β0 + β1 × SNP + ...

结果会发生：

• P 值基本不变（关联强度没有改变）。
• β 的符号相反。
• OR 会变成原来的倒数（1/OR）。

例如真实情况：

可以看到：

• 2.0 ↔ 0.5
• β 正负互换
• P 不变

因此统计显著性不会改变，但生物学解释会相反。

3. 为什么推荐 Case=2？

这是 PLINK 长期采用的默认约定：

1 = unaffected（未患病，对照）
2 = affected（患病，病例）

许多下游分析软件和 GWAS 教程也默认采用这种编码，因此更容易与其他工具和文献保持一致。

4. 如果使用 0/1 可以吗？

对于 PLINK 的标准表型文件：

0 = Missing
1 = Control
2 = Case

不要把 0 当作 Control。

例如：

FID IID PHENO
1   A001 0
2   A002 1
3   A003 2

这里 A001 会被认为是缺失表型，不会参与分析，而不是对照组。

5. 最佳实践

对于你的精神分裂症（SCZ）GWAS，建议统一使用：

FID IID PHENO
1   XJSCZ002 2   # Case
2   XJSCZ003 2   # Case
3   XJSCZ004 1   # Control
4   XJSCZ005 1   # Control

这样得到的结果中：

• OR > 1：风险等位基因（增加 SCZ 风险）。
• OR < 1：保护等位基因（降低 SCZ 风险）。

这种编码方式与大多数 GWAS 文献和 PLINK 默认约定保持一致，也便于后续与 eQTL、PRS 或宏基因组关联分析进行结果解释。