初级和高级程序员的差距，不在语法，而在这7个习惯

async function updateUserProfile(userId, input) {
const user = await getUser(userId);
if (user) {                       // 用户存在吗？
    if (input.email) {              // 邮箱填了吗？
      if (user.canEditProfile) {    // 有权限改吗？
        return saveProfile(user.id, input);  // ← 真正干活的代码在这
      }
    }
  }
thrownewError("更新失败");
}

async function updateUserProfile(userId: string, input: ProfileInput) {
const user = await getUser(userId);

if (!user) thrownew NotFoundError("用户不存在");       // 不满足条件，直接打回
if (!input.email) thrownew ValidationError("邮箱必填");
if (!user.canEditProfile) thrownew ForbiddenError("无权编辑资料");

return saveProfile(user.id, input);  // ← 走到这，说明前面全过了，放心干活
}

嵌套写法（地窖式）                提前返回（保安式）
─────────                        ──────────
if (用户存在) {                   if (!用户存在) 打回
  if (邮箱填了) {                 if (!邮箱填了) 打回
    if (有权限) {                 if (!有权限) 打回
      ...真正逻辑...               ...真正逻辑...（顶格，一眼看到）
    }
  }
}
读者要在脑子里记住：3层状态      读者要记住：0层（看完即忘）

const data = await getData(id);
if (data.status === "active") {
  await process(data);
}

const subscription = await getSubscription(subscriptionId);
if (subscription.isBillable) {          // isBillable = 这笔订阅能不能扣费
  await chargeSubscription(subscription);
}

// 名字长一点没关系，关键是表达清楚业务规则
const usersEligibleForReactivation = await findUsersEligibleForReactivation();
// 一看就懂：符合"可重新激活"条件的用户

const userName = response.data.user_name;
const isActive = response.data.status === "ACTIVE";
const plan = response.data.subscription.plan_name;

// 所有外部数据，先经过这个"翻译官"，转成我们自己说了算的结构
function mapWechatUser(res: WechatUserResponse): Customer {
  return {
    id: res.id,
    name: res.user_name,                          // 对方改字段，只改这一行
    isBillable: res.status === "ACTIVE",
    planName: res.subscription?.plan_name ?? "免费版",
  };
}

   外部世界（你管不着）          墙          内部世界（你说了算）
┌──────────────────────┐    ┌────────┐    ┌──────────────────────┐
│ 微信支付 / 支付宝      │    │ 适配层  │    │  统一的 Customer 模型 │
│ 字段随版本乱改         │ →  │ map()  │ →  │  对方改名？只改墙这一处│
│ 第三方 SDK 响应        │    │ 一处   │    │  其它地方全不动        │
└──────────────────────┘    └────────┘    └──────────────────────┘

type User = {
  id?: string;       // 问号 = 这个字段可能有，也可能没有
  email?: string;
  role?: string;
  status?: string;
};

// 草稿用户：还没存进数据库，所以根本没有 id
type DraftUser = {
  email: string;
  role: "admin" | "member";
};

// 已保存用户：一定有 id 和 status，不用再问"有没有"
type SavedUser = {
  id: string;
  email: string;
  role: "admin" | "member";
  status: "active" | "disabled";
};

type Payment =
  | { state: "pending"; id: string }                          // 待支付
  | { state: "captured"; id: string; receiptId: string }      // 已扣款，才有小票号
  | { state: "failed"; id: string; reason: string };          // 失败，才有原因

// 发收据的函数，只接受"已扣款"的支付
// 如果你传个"待支付"进来，代码编译都过不了 —— 错误在写的时候就被拦住
function sendReceipt(payment: Extract<Payment, { state: "captured" }>) {
  return emailReceipt(payment.receiptId);
}

async function refundInvoice(invoiceId) {
const invoice = await getInvoice(invoiceId);
if (invoice.status !== "paid") thrownewError("未付款，不可退");
if (invoice.refundedAt) thrownewError("已经退过了");
if (invoice.amount <= 0) thrownewError("金额非法");

await paymentProvider.refund(invoice.paymentId);  // 真正退款
await markInvoiceRefunded(invoice.id);            // 改数据库
await sendRefundEmail(invoice.customerId);        // 发邮件
}

// 只负责判断：能不能退？为什么不能退？ 不碰数据库、不发邮件
function getRefundEligibility(invoice: Invoice): RefundEligibility {
  if (invoice.status !== "paid") return { allowed: false, reason: "未付款" };
  if (invoice.refundedAt) return { allowed: false, reason: "已退款" };
  if (invoice.amount <= 0) return { allowed: false, reason: "金额非法" };
  return { allowed: true };
}

async function refundInvoice(invoiceId: string) {
const invoice = await getInvoice(invoiceId);
const eligibility = getRefundEligibility(invoice);   // 先问：能退吗？
if (!eligibility.allowed) thrownew ValidationError(eligibility.reason);

await paymentProvider.refund(invoice.paymentId);     // 能退，再动手
await markInvoiceRefunded(invoice.id);
await sendRefundEmail(invoice.customerId);
}

{ "message": "出错了" }

// 人质式代码：后端哪天把文案改成"邮箱已注册"，这里立刻失效
if (error.message.includes("已存在")) {
  showEmailTakenError();
}

{
  "code": "USER_EMAIL_ALREADY_EXISTS",   // 给程序判断用的错误码，永远不变
  "message": "该邮箱已被注册",            // 给人看的提示，随便改
  "details": { "field": "email" },        // 错在哪个字段
  "requestId": "req_8f91a2"               // 追踪 ID，查日志一搜就到
}

logger.warn("退款被拒", { invoiceId, customerId, reason: eligibility.reason, requestId });

反面教材的提交（活像一张"绑匪勒索信"）：
feat: 更新计费流程
├─ 重构了 invoice 服务
├─ 重命名了支付字段
├─ 改了退款逻辑
├─ 顺手改了看板 UI
├─ 加了 webhook 处理
├─ 改了重试行为
├─ 又顺手修了个状态 bug
└─ 更新了测试
   审查的同事：哪些是必须的？哪些是你顺手改的？bug 藏哪了？😵

PR 1：重命名支付字段（不改任何行为）
PR 2：新增"退款资格判断" + 测试
PR 3：把退款判断接进计费流程
PR 4：看板 UI 展示退款原因
PR 5：加 webhook 重试