{sub}
}{children}
{cap && | 维度 | 实测 | 后果 |
|---|---|---|
| {a} | {b} | {c} |
表面看，换一套主题最便宜。但老站的技术栈是 2015 年前后的国产生态组合：The7 + Visual Composer + Revolution Slider。这套组合的问题不在于"老"，而在于它把内容固化在页面构建器的私有数据结构里，任何形式化重构都要先做一次内容解析。
更关键的是：WordPress + 20 个插件 + PHP 动态渲染，意味着每一次访问都是一次数据库查询与模板渲染。当访问量出现尖峰（比如一条公众号推文带来的流量），PHP-FPM 进程会被打满，这就是"经常宕机"的直接机制。
重做一次前端，等于同时解决四件事，而它们的投入并不相同：
{c}
{` ┌──────────────────────────┐
读者 / 学员 ───────▶ │ CDN + 静态对象存储 │ ← 全站预渲染 HTML
│ (OSS/COS + CDN 回源) │ 0 次数据库查询
└──────────▲───────────────┘
│ deploy（构建产物上传）
┌──────────┴───────────────┐
│ CI/CD：Git push → 构建 │
│ Next SSG / Astro │
└──────────▲───────────────┘
│ 读（构建时）
┌──────────────────────────┴───────────────────────────┐
│ 应用层（容器，2 副本） │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 内容 API │ │ 微信网关 │ │ 报名/预约 │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
└───────┼─────────────┼─────────────┼──────────────────┘
│ │ │
┌───────▼──────┐ ┌────▼─────┐ ┌─────▼──────┐
│ PostgreSQL │ │ 任务队列 │ │ Redis │
│ + 对象存储 │ │ (BullMQ) │ │ 会话/限流 │
└──────────────┘ └────┬─────┘ └────────────┘
│ 定时/事件
┌─────────▼──────────┐
│ 公众号同步 Worker │──▶ 微信服务器 (AppID/AppSecret)
└────────────────────┘`}
前台静态化：页面在发布时生成 HTML，推送到 CDN。读者访问的是 CDN 边缘节点，即使应用层完全挂掉，全站仍然可读。这是把"宕机"从概率事件变成架构上不可能的最直接手段。
应用层只服务写操作与动态查询：登录态校验、报名提交、预约创建、后台管理。它的 QPS 需求比前台低两个数量级，两台小规格容器足够。
队列解耦同步任务：公众号抓取是外部依赖，必须异步。抓取失败不该影响任何人访问站点。
{c}
{`[cron 每 15 分钟 / 手动触发]
│
▼
1. FETCH 调用微信接口，按 offset 拉取最近 N 篇（增量：以 last_sync_at 去重）
│ ↓ 幂等键：wx_article_id（微信侧唯一）
▼
2. PARSE 正文 HTML → 结构化块（段落/标题/图片/引用/表格）
│ 剔除：微信内联 style、mp-profile 卡片、赞赏/在看按钮、
│ 历史文章推荐、"点击上方蓝字"引导语
▼
3. ASSET 图片：下载原图 → 去 EXIF → 转 WebP（质量 82）→ 上 CDN
│ 保留原始尺寸的 2x 用于 retina；禁止外链微信图床（防盗链会裂图）
▼
4. CLASSIFY 规则 + 关键词匹配分类（入门/案例/课程/征稿）
│ 命中「医疗」「疗效」「治愈」等词 → 打 requires_review 标记
▼
5. REVIEW 命中标记的进人工队列；其余进入 ready 待发布
▼
6. PUBLISH 立即发布 or 定时 → 触发前台 ISR 重建单页 → 记录版本快照`}
微信文章的 HTML 有三个特点：全内联样式、大量结构性冗余（每段都包了 2–3 层 section 容器）、图片带防盗链。直接存下来再渲染，会导致：样式与站点冲突、复制粘贴失效、图片外链在别的域名下裂掉。
{`strip_inline_styles 移除 style 属性，保留语义标签
unwrap_empty_sections 无内容时提升子节点
strip_profile_card class 含 mp_profile / js_profile → 删除
strip_reward id 含 js_reward / 赞赏 → 删除
strip_follow_cta "点击上方蓝字"/"长按识别二维码" 段落 → 删除
strip_history_links class 含 js_article_history → 删除
normalize_images data-src → 存本地 CDN 地址；补 alt
map_headings 伪标题 → h2/h3（按字号启发式）
dedupe_paragraphs 连续重复段落（微信编辑器常见）→ 去重`}
微信的网页授权（`snsapi_base` / `snsapi_userinfo`）仅对认证服务号开放。订阅号即使认证，也无法调起授权页。所以"在网页里点一下微信登录，直接拿到 openid"这条路，在订阅号上不存在。
可行的替代是带参二维码：后端生成一个临时二维码，携带一个一次性 ticket；用户扫码后，微信把 `subscribe`（新关注）或 `SCAN`（已关注）事件推给你的服务器，事件里带着 `Ticket` 与 `FromUserName`（即 openid）；服务器把两者绑定，前端轮询发现 ticket 已绑定，即完成登录。
{`前端 API 微信服务器 用户微信
│ │ │ │
│ ① 请求登录 │ │ │
├──────────────────▶│ │ │
│ │ ② qrcode/create │ │
│ │ scene_str=ticket │ │
│ ├──────────────────────▶│ │
│ │◀── ticket + url ──────┤ │
│◀─ {ticket, qr_url,│ │ │
│ expires_in:180} │ ③ 存 redis: │ │
│ │ qr:{ticket} = │ │
│ │ {status:'waiting'} │ │
│ ④ 渲染二维码 │ │ │
│ │ │ ⑤ 用户扫码 │
│ │ │◀───────────────────┤
│ │ ⑥ 事件推送 POST │ │
│ │ MsgType=event │ │
│ │ Event=subscribe │ │
│ │ EventKey=qrscene_… │ │
│ │◀──────────────────────┤ │
│ │ ⑦ 校验签名 → 写 │ │
│ │ qr:{ticket}={ │ │
│ │ status:'subscribed',│ │
│ │ openid } │ │
│ ⑧ 轮询 GET │ │ │
│ /auth/qr/:ticket │ │ │
├──────────────────▶│ │ │
│◀─ {status: │ │ │
│ 'subscribed'} │ │ │
│ ⑨ 补资料 → POST │ │ │
│ /auth/complete ├──────────────────────▶│ 建 user + session │
│◀─ Set-Cookie ─────┤ │ │
│ ⑩ 回到原操作 │ │ │
│ （收藏/报名） │ │ │`}
你选的是"仅功能性"门禁。这是对的——内容站用强制登录换关注，几乎必然掉流量与 SEO；而收藏、报名、预约、下载这些动作本身就需要身份，拦住它们不损失任何东西。
{b}
{`-- 用户（来自公众号关注）
create table users (
id bigserial primary key,
openid text unique not null, -- 微信 openid
unionid text, -- 若绑定开放平台
nickname text, -- 需用户自行填写（订阅号拿不到）
contact_time text, -- 方便联系的时间偏好
source text, -- article / menu / search
subscribed_at timestamptz default now(),
unsubscribed_at timestamptz, -- 取关时间（事件推送）
tags text[] default '{}'
);
-- 会话
create table sessions (
id text primary key, -- 随机 32 字节
user_id bigint references users(id) on delete cascade,
expires_at timestamptz not null,
ip inet, ua text
);
-- 文章（同步 + 手工）
create table posts (
id bigserial primary key,
wx_article_id text unique, -- 幂等键，手工文章为 null
slug text unique not null,
title text not null,
excerpt text,
cover_url text,
body jsonb not null, -- [{type:'p',text:…},{type:'h2',…}]
category text not null,
status text not null default 'draft', -- draft|review|ready|published|archived
requires_review boolean default false,
published_at timestamptz,
source text default 'wechat', -- wechat | manual
read_count int default 0
);
create index on posts using gin (body jsonb_path_ops);
create index on posts (status, published_at desc);
-- 同步任务（可重入）
create table sync_jobs (
id bigserial primary key,
wx_article_id text,
stage text not null, -- fetch|parse|asset|classify|review|publish
state text not null, -- queued|running|ok|failed
error text,
attempts int default 0,
started_at timestamptz, finished_at timestamptz
);
-- 版本快照（回滚用）
create table post_versions (
id bigserial primary key,
post_id bigint references posts(id) on delete cascade,
snapshot jsonb not null,
editor_id bigint,
note text,
created_at timestamptz default now()
);
-- 课程与报名
create table courses (
id bigserial primary key, slug text unique, title text, level text,
form text, language text, price_cents int, seats int,
starts_at timestamptz, status text default 'draft'
);
create table enrollments (
id bigserial primary key,
course_id bigint references courses(id),
user_id bigint references users(id),
name text, city text, phone text,
payment text default 'pending', -- pending|paid|refunded
source text,
created_at timestamptz default now(),
unique (course_id, user_id)
);
-- 催眠师名录
create table practitioners (
id bigserial primary key,
user_id bigint references users(id),
display_name text, city text, level text,
cert_no text unique, cert_verified_at timestamptz,
specialties text[], bio text,
status text default 'pending', -- pending|active|suspended
approved_by bigint, approved_at timestamptz
);
-- 预约工单
create table bookings (
id bigserial primary key,
user_id bigint references users(id),
practitioner_id bigint references practitioners(id),
preferred_at timestamptz, note text,
status text default 'new', -- new|contacted|scheduled|done|cancelled
assigned_to bigint, -- 客服
created_at timestamptz default now()
);
-- 操作日志（写操作全留痕）
create table audit_logs (
id bigserial primary key, actor_id bigint, action text,
target_table text, target_id bigint,
before jsonb, after jsonb, ip inet,
created_at timestamptz default now()
);`}
{d}
最小可用的监控只需要三件事：可用性探测（每 1 分钟请求首页与一个动态接口）、构建失败告警（推送到企业微信/邮件）、同步任务失败告警（连续 3 次失败才告警，避免噪音）。
不要一上来就搭完整 APM。先把"挂了会不会有人知道"这个问题解决。
| {h} | )}||||
|---|---|---|---|---|
| 0{i + 1} {s[0]} | {s[1]} | {s[2]} | {s[3]} | {s[4]} |
{`# 1. 从 sitemap / RSS / 站内链接爬全量 URL
curl -s "https://www.qhhtchina.com/?feed=rss2" \\
| grep -oP '(?<=)[^<]+' | sort -u > urls.txt
# 2. 抓取快照并统计结构（判断提取难度）
while read u; do
f="snap/$(echo "$u" | md5sum | cut -c1-12).html"
curl -sL "$u" -o "$f"
echo "$u | $(wc -c <"$f") | $(grep -c ' inventory.tsv
# 3. 输出分布，判断是否值得全量迁移`}
目前已知：RSS 只暴露 10 条，最新一篇 2019-05。这说明至少有一批内容没进 RSS（页面 ID 已经到 18183，而 RSS 只有 10 条），必须靠 sitemap 或站内链接爬取才能拿到全量。
预算或时间不足时的优先级：P0 → P3（迁移）→ P1（同步）→ P2（登录）。
理由：先把"能打开、不宕机、内容分层"这三件最影响信任的事做完，再谈增长。同步与登录是效率与转化工具，晚两周上线不影响站的成立。
{d}
↳{why}