从今年开始，公司开始全员推广AI编程，并提供Cursor账号给大家使用。经过三个多月的深度使用，在此分享我的一些真实体验与感受。

AI编程辅助工具的发展历程 ​

从ChatGPT到目前各种AI编程助手和智能编辑器，AI辅助编程工具的发展可以大致分为三个阶段：

生成式阶段 ​

最初的AI编程辅助仅限于对话式生成，且生成质量一般。使用这类工具辅助编程需要在AI聊天窗口和代码编辑器之间不断切换，频繁复制粘贴，体验非常繁琐。虽然后来编辑器中出现了大量封装AI对话的插件，但交互依然不够顺畅，仍需手动在不同界面间复制代码。

在这个阶段，我的使用主要集中在早期尝鲜阶段，新鲜感过后便将其降级为高级搜索引擎使用。

交互式阶段 ​

Cursor在早期虽然其他功能表现平平，但它之所以能迅速走红，很大程度上源于其创新的交互设计。它能基于本地代码建立索引，根据项目上下文提供更智能的代码提示和修改建议，并通过Tab键快速应用这些修改（Tab键功能的便捷性无需多言，用过的人都懂😂）。

执行式阶段 ​

随着Cursor等工具的交互模式获得认可，AI编程工具的能力边界进一步扩展。现代AI编程助手不仅能生成代码，还能直接执行并根据运行结果进行优化。例如，当你需要处理文件夹中的文件时，之前的AI只会生成代码而不会执行；如今的AI则能运行生成的代码，根据执行结果自动修复错误或进行下一步操作。

这种进化显著提升了开发效率，特别是对非专业程序员更为友好。

个人使用体验 ​

在这三个月的Cursor深度使用过程中，我主要在以下几个方面获益良多：

项目代码分析 ​

作为公司新人，面对多样化的项目架构和技术栈，快速理解代码成为首要挑战。AI工具在此环节表现出色，帮助我迅速梳理项目结构和代码逻辑。有时候连我自己都需要花时间理解的代码片段，AI已经能够逐行分析并提供清晰解释。

对于代码中的疑点，直接向AI提问往往比翻阅文档更加高效。

复杂技术规范解析 ​

办公软件在线化是个技术挑战，尤其是涉及到OOXML等规范时。这类规范文档通常分为多个部分，每部分都是数千页的英文PDF，对不熟悉的开发者极不友好。

在需要解析PPT文件并进行二次编辑时，我直接向AI咨询相关技术细节，它不仅能解释概念，还能根据项目实际需求提供针对性解决方案。甚至可以直接将XML片段交给AI，让它提取关键信息并转换为网页可用的CSS值。

代码重构与优化 ​

为求速度，我有时会将功能实现集中在单个文件中。作为曾接手过"屎山"代码的开发者，我深知这种做法的后患。在无法立即进行组件拆分的情况下，我通常选择先完成业务功能，再交由AI进行代码拆分和封装。

向AI明确提出重构需求，再根据反馈进行调整，这种方式既保证了开发速度，又维持了代码质量。更值得称赞的是，AI重构后的代码通常能直接运行，免去了大量调试时间。

环境搭建与小需求快速解决 ​

AI在简化工作流方面表现突出。比如需要批量处理文件时，AI能根据需求生成脚本，指导执行过程，并根据执行结果进行修复。使用者只需按提示操作即可。

例如，尽管我后端知识已经淡忘，Python也几乎没接触过，但在AI的辅助下，我依然能够编写简单的Python后端代码。环境配置过程中，AI会提供详细指引，甚至在遇到国外源不可用时，主动帮我切换到国内镜像，体现了超出预期的智能水平。

另一个实例是，我需要将大量视频文件按特定格式上传至云存储，本地文件名虽有规律但信息不完整。本想手动处理，却尝试让AI协助，结果几分钟就完成了可能需要我花费数小时的整理工作。

代码智能提示 ​

Cursor的Tab补全功能堪称神器，它能基于本地代码和项目结构智能预测下一步操作。"一直Tab一直爽"并非夸张之词。

实际使用中，当修改组件CSS字体大小时，AI常能预测到其他关联部分也需要调整，准确率相当高。如今的代码提示已经进化到我正在输入代码的同时，AI已经预生成了后续内容的地步。

跨语言代码转换与生成 ​

在参考其他语言实现的功能时，AI能够快速将代码转换为目标语言，省去了人工"翻译"的麻烦。大部分转换后的代码无需大幅调整即可运行。

向AI描述需求时，我发现一些技巧：尽量详细描述功能，避免过于宏大的任务，最好将大任务分解为小步骤逐一实现。若直接提出复杂需求，AI容易"卡壳"甚至开始胡乱生成代码。

使用中的不足之处 ​

尽管AI编程工具带来诸多便利，使用过程中也存在一些值得注意的问题：

内容不准确 ​

虽然现代AI比早期版本强大许多，但仍存在"幻觉"问题，有时会生成不准确内容。更令人困扰的是，即使指出错误，AI可能口头认同却不实质性修正问题。这种情况部分源于提示不当，部分则是AI能力限制。

意图理解偏差 ​

有时我只需AI提供思路，它却直接修改代码；有时需要具体实现，它却只给出概念性指导。这种意图理解的不一致让人难以把握，需要通过不同提示词来引导。早期Cursor将对话和生成分开设计，现在功能整合后反而产生了一些混淆。

弱化思考能力 ​

过度依赖AI实现功能会导致一种"失控感"，因为代码逻辑并非源自自己思考，而是AI直接生成。当AI编码风格与个人习惯不符时，甚至需要"反向学习"AI的实现方式。这时，要求AI详细解释实现逻辑就显得尤为重要。

总结 ​

总体而言，AI编程工具确实显著提升了开发效率。在回归传统编辑器后，没有智能提示的编码体验甚至让人有些不适应。

最近需要做一些项目验收相关的事，结合网上的别人的经验和自己实操，整理一些需要清单和要做的事情。

项目验收 ​

存档文档 ​

• 项目架构设计文档
• 数据库设计说明书
• 接口设计说明书
• 代码结构文件说明书
• 编码规范和数据库设计规范
• 原型或PRD
• 系统操作手册
• 质量分析报告
• 服务器软硬件环境配置说明书

验收准备 ​

• 提供演示站点
• 将要交付的软件安装于指定服务器，并完成调试和上线。
• 文档齐全，文档内容需要描述完整并没有歧义，对主要功能和关键操作尽量提供应用实例。

界面验收 ​

• PC 端需要适配现代浏览器 谷歌、edge、火狐、safari...等
• 移动端需要适配主流设备 iphone、华为、小米、vivo、oppo... 等

功能验收 ​

• 功能验收范围覆盖（接口、数据库存取、页面功能）
• 提供单元测试用例、集成测试用例和系统测试用例

性能验收 ​

• 提供BUG管理跟踪记录表
• 提供质量分析报告
• 提供性能测试报告

安全验收 ​

• 软件中的敏感数据需以密文方式存储
• 软件需有留痕功能，即保存用户的操作日志、系统异常日志、接口调用数据日志等
• 软件中各种用户的权限分配合理

用户验收 ​

• 外包团队需提供稳定的用户验收环境
• 业务场景功能测试，不得出现严重 BUG
• 所有提交的问题都已得到修复

源码交接 ​

源码交接前提 ​

• 涉及交接的软件，原则上建议接受交接软件所有功能，不建议交接软件部分功能模块
• 线上稳定运行既线上可用率，需满足：最近3至6个月内，线上没有出现影响20人以上或数据错误的严重bug，且每月线上bug数不超过3个

源码验收规范 ​

• 代码应只保留跟本项目相关的代码，无效代码应一律去除
• 数据库应只保留跟本项目相关的表、视图、存储过程、函数、触发器、定时job等，无效内容应一律去除
• 特别注意合理做好数据表结构设计，适当冗余提升性能
• 代码结构清晰无冗余，注释完整有效，避免硬编码
• 但凡不符合源码验收规范的，外包团队需修复完毕

其他 ​

• 售后服务
• 培训计划

这篇文章是什么呢? 就是如题所述告诉你如何自定义极简的博客主题。

需求 ​

vitepress 是什么 ​

VitePress 是一个静态站点生成器 (SSG)，专为构建快速、以内容为中心的站点而设计。简而言之，VitePress 获取用 Markdown 编写的内容，对其应用主题，并生成可以轻松部署到任何地方的静态 HTML 页面。

功能需求 ​

首先确定我们开发一个主题需要哪些页面和功能，一个极简的博客可以只需要下面三个页面。加载文章数据生成首页，以及显示文章的详情页

• 首页
• 文章详情页
• 404 页

实现 ​

需要注意的是 vitepress 自定义主题需要区分哪些是运行在 node 环境的，哪些是运行在 浏览器 上的。

只运行在 node 中的

• 配置文件 config.ts
• 构建是加载数据 .data.js 或 .data.ts 结尾文件

node 和 浏览器都会运行的

• SFC 文件，因为使用的 SSR 渲染，所有需要注意使用范围

原则上只在 Vue 组件的 beforeMount 或 mounted 钩子中访问浏览器或 DOM API。

自定义主题 ​

vitepress 想要自定义主题，只需要在主题启动入口文件里申明使用自定义主题即可 ( .vitepress/theme/index.js 或 .vitepress/theme/index.ts 为主题入口文件)

.
│─ .vitepress
│  ├─ theme
│  │  └─ index.ts   # 主题入口
│  └─ config.ts     # 配置文件
│─ index.md
└─ package.json

在入口文件中导出根布局组件，Layout.vue 会替代 vitepress 默认主题进行页面的渲染，让我们从 Layout.vue 开始完善一个完整的主题吧。

// .vitepress/theme/index.ts

// 可以直接在主题入口导入 Vue 文件
import Layout from "./Layout.vue";
export default {
  Layout, // 每个页面的根布局组件
};

在开始之前，我们确定我们项目页面结构组成，暂定为如下目录结构，将文章集中放在 _posts 目录下

.
│─ .vitepress
│  ├─ theme
│  │  └─ index.ts   # 主题入口
│  └─ config.ts     # 配置文件
│─ _posts # 文章存放目录
│  ├─ xxxx.md
│  └─ xxxx.md
│─ index.md # 首页
└─ package.json

加载 _posts 文章 ​

首页里的内容除了通用的布局样式之外 (导航、侧栏、横幅、....) 主要的就是文章列表了，我们先来实现对 _posts 目录下文件加载和分页，以及文章置顶排序等实现。

在 vitepress 提供了构建是加载数据的钩子，我们可以自定义加载数，并且在页面中使用它。使用方式也很简单只需要文件 .data.js 或 .data.ts 结尾即可。

我们添加 posts.data.ts 文件，大致流程就是 读取文件 => 处理 frontmatter 参数、摘要、内容 => 对文章排序处理

需要注意的是: .data.ts 是运行在 node 环境下的，避免使用浏览器的 api

export default {
  watch: ["_posts/**/*.md"],
  // files 是一个所匹配文件的绝对路径的数组。
  load(files) {
    // 使用 vitepress 内置 渲染插件渲染 md 文件里提取摘要信息
    md = md || (await createMarkdownRenderer(config.srcDir, config.markdown, config.site.base, config.logger));
    const raw = [];
  },
};

通过 fs 读取文件内容和文件信息，以及文件信息(创建时间 和 修改时间)，可以将生成的文章信息缓存起来，通过判断 mtimeMs 是否变更来判单是否需要重新生成。

const { mtimeMs: timestamp, birthtimeMs } = fs.statSync(file);
const cached = cache.get(file);

if (cached && timestamp === cached.timestamp) {
  raw.push(cached.data);
  continue;
}

使用 gray-matter 库来提取 md 文件里的 YAML frontmatter 信息，在 gray-matter 里 excerpt 添加摘要生成函数。

const fileContent = fs.readFileSync(file, "utf-8");
let excerpt = "";
const { data: meta } = matter<string, any>(fileContent, {
  excerpt: ({ content }: matter.GrayMatterFile<string>) => {
    const reg = /<!--\s*more\s*-->/gs; //  将 <!-- more --> 前面内容视为摘要格式
    const rpt = reg.exec(content);
    excerpt = rpt ? content.substring(0, rpt.index) : "";
  },
});

获取文章创建时间，取值规则如下 md => git => file，先去 frontmatter 里声明时间，然后获取 git 提交时间，如果前面两个都没获取到则获取文件的时间。

frontmatter 和 文件创建时间 上面都以及获取到了接下来主要是获取 git 提交时间 ，主要是通过 git log 命令获取文件信息。

node 实现如下

import { spawnSync } from "node:child_process";

function getFileBirthTime(url: string) {
  try {
    // ct
    const infoStr = spawnSync("git", ["log", '--pretty="%ci"', url]).stdout?.toString().replace(/["']/g, "").trim();
    const timeList = infoStr.split("\n").filter((item) => Boolean(item.trim()));
    if (timeList.length > 0) {
      return new Date(timeList.pop()!).getTime();
    }
  } catch (error) {
    return undefined;
  }
}

渲染摘要信息 和 处理文件路径

let url = normalizePath(path.relative(config.srcDir, file));
url = config.rewrites.map[url] ?? url;
url = "/" + url.replace(/(^|\/)index\.md$/, "$1").replace(/\.md$/, config.cleanUrls ? "" : ".html");

const renderedExcerpt = excerpt ? md.render(excerpt) : void 0;
const data = {
  excerpt: renderedExcerpt,
  ...meta,
  url: withBase(config.site.base, url),
  filePath: slash(path.relative(config.srcDir, file)),
};
cache.set(file, { data, timestamp });
raw.push(data);

对生成数据进行排序并返回

return sortBy(raw, "-date");

页面布局 ​

对文章的数据加载已经实现 ，在布局组件里直接导入 post.data 文件， layout 为 home 视为首页, 其他则为文章详情页面 。

<script setup lang="ts">
import { useData } from "vitepress";
import { data as allPosts } from "./post.data";
import { formatDate } from "./util/client";
const { page } = useData();
</script>

<template>
  <div v-if="page.isNotFound">404</div>
  <template v-else>
    <div v-if="page.frontmatter.layout === 'home'" class="post-list">
      <div v-for="item in allPosts" class="post-list-item">
        <a :href="item.url">
          <span>{{ item.title }}</span>
          <span>{{ formatDate(item.date, "YYYY-MM-dd") }}</span>
        </a>
      </div>
    </div>
    <template v-else>
      <div class="post-title">
        <div>{{ page.title }}</div>
        <a href="/">返回</a>
      </div>
      <div class="post-info">
        <Content />
      </div>
    </template>
  </template>
</template>

把所有页面逻辑都写在一个页面会难以维护 ，我们拆分一下

<template>
  <NotFoundPage v-if="page.isNotFound" />
  <template v-else>
    <HomePage v-if="page.frontmatter.layout === 'home'" />
    <PostPage v-else />
  </template>
</template>

实现分页 ​

在 HomePage 对 allPost 实现前端分页，根据当前 currentPage 和 pageSize 将文章数组进行拆分

const currentPage = ref(1);
const pageSize = 3;

// 当前页显示 文章
const curPageList = computed(() => {
  const startIdx = (currentPage.value - 1) * pageSize;
  const endIdx = startIdx + pageSize;
  return allPosts.slice(startIdx, endIdx);
});

根据当前页码信息，生成一个简易分页组件数据

// 页码生成
const pageList = computed(() => {
  const count = Math.ceil(allPosts.length / pageSize);
  if (count > 5) {
    const list = [1, currentPage.value - 1, currentPage.value, currentPage.value + 1, count].filter((i) => i > 0 && i <= count);
    return [...new Set(list)];
  } else {
    return new Array(count).fill(null).map((_v, i) => i + 1);
  }
});

将模板中遍历 allPosts 替换成 curPageList ，并渲染出页码信息，切换页码时候设置 currentPage 就可以了

自定义配置 ​

在上面都是将一些信息写死在代码中的，vitepress 提供了注册配置方式的，我们可以将主题中的一些参数写入到配置中。

.vitepress/config.ts 是 vitepress 加载配置的文件, 我们要自定义主题所以不能在使用 vitepress 提供的 defineConfig 方法。

如果时仅仅自己使用，可以直接导出我们配置就可以了

import { UserConfig } from "vitepress";
const themeConfig = {};
export type ThemeConfig = typeof themeConfig;
export default {
  title: "vitepress-demo",
  description: "viteoress 自定义主题示例",
  themeConfig, // 这里将配置我们主题的配置
} as UserConfig<ThemeConfig>;

比如我们上面存在文章的目录、页码 等等都可以写在配置里, 以方便细粒度配置。

const themeConfig = {
  pageSize: 3,
  sort: "-date",
  postDir: "_posts",
};

在主题中可以通过 vitepress 提供 useData 使用

const { theme } = useData<ThemeConfig>();

如果我们需要将主题发布到 npm 供其他人使用，当主题更为复杂的时候，会有更多的配置，所有我们需要处理主题默认的配置 和 用户配置合并，提供的 defineConfig 方便用户的使用

import { mergeConfig as mergeViteConfig } from "vite";
import type { UserConfig } from "vitepress";

export const defineConfig = (config: UserConfig<ThemeConfig>) => {
  config = mergeConfig(defaultConfig, config);

  // 可以在这里处理一些 配置合并问题

  return config;
};

总结 ​

本文中使用到的代码示例可以在 stackblitz 上查看

一个复杂的主题当然还会有更多的共功能，页面中更良好的布局，那些都是在此基础上进行的扩展。

安利一下我写的 hexo 和 vitepress 主题

• vitepress-theme-async
• hexo-theme-async

最近抽空把博客从 hexo 转移到 vitepress 了，也对 vitepress-theme-async 进行了一波爆更，整体迁移还算比较顺利。大部分的功能都已经处理完了，部分原来需要三方插件支持功能还没支持。

有需要从 hexo-theme-async 迁移到 vitepress-theme-async 的可以 参考文档这里

之前文档一直使用的是 vitepress 搭建的，体验感觉也挺好的，所以萌生了想移植到 vitepress 上去。为什么不是选择 vuepress，是因为 vitepress 更加轻量更快。

早在几个月前就完成了 hexo-theme-async 大部分功能的移植，但是因为在使用 vitepress 自定义加载数据出现了一些问题（参考这里），没有进行下去，想着等 vieptepres 从 rc 到正式发布会不会处理这个问题，最终 1.0 发版时这个问题还是存在，只好修改主题实现方式避免这个问题。

快速开始 ​

创建一个新的博客 ​

$ npm create async-theme@latest my-first-blog

运行查看效果 ​

$ vitepress dev ./

地址 ​

• 文档地址
• 源码地址
• 在线体验地址

支持功能 ​

基本上 UI 上的功能，已经基本完善实现了。一些插件类功能本身 vitepress 也支持，所以没有移植处理。

• ✅ 语言切换
• ✅ 主题模式
• ✅ 搜索模块
• ✅ 顶部导航模块
• ✅ 侧栏模块
• ✅ 横幅模块
• ✅ 页脚模块
• ✅ 固定按钮区域模块
• ✅ 分页模块
• ✅ 打赏模块
• ✅ 版权信息模块
• ✅ 上下篇模块
• ✅ 文章封面模块
• ✅ 过期提醒模块
• ✅ 友接页
• ✅ 关于页
• ✅ 归档页
• ✅ 标签页
• ✅ 分类页
• ✅ 全局组件
• ✅ 自定义插槽
• ✅ 自定义图标
• ✅ 自定义样式
• ✅ 自定义组件
• ✅ RSS 插件

关于 Hexo 如何开发主题包的教程已经是大把的存在了，这里就不再赘述了。这篇文章主要讲的是作为一个主题的开发者，如何让你的主题具有更好的扩展性，在用户自定义修改主题后，能够更加平易升级主题。

问题所在 ​

Hexo 提供两种方式安装主题包：

• 直接在 themes 目录下直接存放主题包文件，这种方式用户可以很方便的魔改主题，但是魔改后升级主题会变得比较困难
• 通过 npm 安装主题包，这种方式更加方便用户升级主题，但是不易扩展现有的主题。

当用户想要自定义修改主题时，基本上只能通过第一种方式安装，且只能通过修改 源代码 形式去修改主题。这样带来的问题就是，当主题修复一些 bug 或者主题迭代 N 个版本后，用户想升级主题时就会变的比较麻烦。

有没有能让用户方便升级，又能提供一定个性化的能力的东西呢？答案是有的，那就是通过 npm 方式分发主题包，我们通过一些魔法，让其有一定的扩展能力，这篇文章就来讲解如何实现它。

模板 ​

在 Hexo 中，主题的模板决定的网站页面程序的方式，当你不同页面结构很相似时候，可以通过布局（Layout）去复用相同的结构，而相似的部分可以抽离成通用局部模板，通过使用 Partial 去加载，以达到模板复用的效果。

这就是 Hexo 在开发主题处理模板复用的方式，可把一个个局部模板理解为一个个独立的组件，哪里需要是就在哪里加载它。如果说用户想替换某一个局部模板，我们可以让用户提供一个新的模板，然后去加载用户提供的模板，那是不是达到在用户不修改源代码情况下对主题进行个性话的扩展呢。

Partial ​

要想知道 Hexo 是如果加载局部模板的，翻看下 Hexo 源码里 Partial 的实现（/plugins/helper/partial.js），可以看到是通过调用 ctx.theme 获取到对应的 view，接着调用 render 渲染的。

const { dirname, join } = require("path");

module.exports = (ctx) =>
    function partial(name, locals, options = {}) {
        const viewDir = this.view_dir;
        const currentView = this.filename.substring(viewDir.length);
        const path = join(dirname(currentView), name); // 根据当前路径找到，局部模板路径
        const view = ctx.theme.getView(path) || ctx.theme.getView(name); // 根据路径去匹配 view
        const viewLocals = { layout: false };
        // Partial don't need layout
        viewLocals.layout = false;
        return view.renderSync(viewLocals);
    };

Hexo 对文件处理分为两种，一种是 source 目录文件处理，一种是对主题包里文件处理。在辅助函数注册里可以看 ctx 其实就是 hexo 运行时的实例，上面的 ctx.theme 就是主题文件处理的 Box。通过 Hexo 提供 api 可以看到，它不仅提供了 getView，还提供了 setView、removeView 方法。

然后翻看 setView 代码，可以看到当你重新设置一个新的 view 时，它会覆盖掉已有的 view。也就是说我们可以直接覆盖主题里的 局部模板

  setView(path, data) {
    const ext = extname(path);
    const name = path.substring(0, path.length - ext.length);
    this.views[name] = this.views[name] || {};
    const views = this.views[name];

    views[ext] = new this.View(path, data);
  }

修改示例 ​

以覆盖 hexo-theme-async 为示例，在生成前钩子 generateBefore 里，覆盖掉主题里默认的侧栏模板。

hexo.on("generateBefore", () => {
    hexo.theme.setView("_partial/sidebar/index.ejs", "<div>111</div>");
});

运行起来会发现侧栏模板已经替换成我们写的 111 了。

主题实现 ​

通过上面方式确实可以达到覆盖主题默认模板能力，但是让用户直接修改会很不友好，需要自己去看主题中局部模板的路径信息，并且还需要自己编写加载文件内容，覆盖主题默认模板逻辑。

可以将这部分操作内置进入主题内处理，只需要让用户编写自己的模板，以及告诉我们需要替换对应模板即可。大致流程如下：

还可以提供默认配置，简化通过路径覆盖

通过在配置中配置好主题中使用的局部模板，类似这样，将主题中使用的局部模板以配置形式展示。

layout:
    path: layout
    # layout
    main: _partial/main
    header: _partial/header
    banner: _partial/banner
    sidebar: _partial/sidebar/index
    footer: _partial/footer

接着在加载局部模板时，直接读取配置的信息，当用户覆盖掉了 layout.header 时候，主题就会自动使用新的模板了。

<%- partial(theme.layout.header) %>

模板加载实现 ​

根据上面配置，约定 layout.path 配置指向目录为用存在模板目录，以便可以自定义存放路径。

layout:
    path: layout

首先就是根据配置获取模板存在的绝对路径，可以根据 hexo 实例，获取到根目录，拼接出完整路径位置。

const { resolve } = require("path");
const layoutDir = resolve(hexo.base_dir, hexo.theme.config.layout.path);

然后是对文件目录的监听，这个可以直接使用 hexo-fs ，避免安装额外的依赖包，提供了新增、删除、修改、文件夹变动的监听，可以针对不同事件做出不同操作。

const { watch } = require("hexo-fs");

watch(layoutDir, {
    persistent: true,
    awaitWriteFinish: {
        stabilityThreshold: 200,
    },
}).then((watcher) => {
    watcher.on("add", (path) => /** 设置模板 */);
    watcher.on("change", (path) => /** 设置模板 */);
    watcher.on("unlink", (path) => /** 移除模板 */);
    watcher.on("addDir", (path) => /** 添加文件夹，递归遍历设置模板 */);
});

因为上面是通过配置去加载模板的，所有为了避免用户自定义的模板名称会与主题的模板名称冲突，导致覆盖了主题的模板，可以在使用时增加一个约定的前缀，避免重名，需要对设置模板进行简单封装。

const setView = (fullpath) => {
    const path = "async" + fullpath.replace(layoutDir, ""); // 约定固定前缀为 async
    hexo.theme.setView(path, readFileSync(fullpath, { encoding: "utf8" }));
};

上面处理方式，用户自定义模板，可以正常加载使用的，但是当自定义的模板又引入了其他模板时会存在一个问题，在有的模板引擎中会出现路径不正常。通过查看 view 实例信息，可以看到其指向目录是在 node_modules，而实际上是存在根目录的。

翻看 view 源码可以看到 source 是获取的 this._theme.base ，而 this._theme.base 往上找就 theme_dir，也就是主题存放的目录，最后又通过 renderer.compile 设置模板渲染到，导致传入 path 不正确。

知道了原因我对上面代码进行修正，设置后重新获取到 view，然后手动根据路径信息。

const setView = (fullpath) => {
    const path = "async" + fullpath.replace(layoutDir, ""); // 约定固定前缀为 async
    hexo.theme.setView(path, readFileSync(fullpath, { encoding: "utf8" }));

    const view = hexo.theme.getView(path);
    view.source = fullpath; // 修正原文件路径
    view._precompile(); // 重新调用渲染器的初始化
};

将上面操作，放置在在 Hexo 的 generateBefore 中：

const { resolve } = require("path");
const { watch, readdirSync, statSync } = require("hexo-fs");

hexo.on("generateBefore", () => {
    const layoutDir = resolve(hexo.base_dir, hexo.theme.config.layout.path);

    const setView = (fullpath) => {
        const path = "async" + fullpath.replace(layoutDir, ""); // 约定固定前缀为 async
        hexo.theme.setView(path, readFileSync(fullpath, { encoding: "utf8" }));
        const view = hexo.theme.getView(path);
        view.source = fullpath; // 修正原文件路径
        view._precompile(); // 重新调用渲染器的初始化
    };

    watch(layoutDir, {
        persistent: true,
        awaitWriteFinish: {
            stabilityThreshold: 200,
        },
    }).then((watcher) => {
        watcher.on("add", (path) => setView(path));
        watcher.on("change", (path) => setView(path));
        watcher.on("unlink", (path) => {
            const path = "async" + path.replace(layoutDir, "");
            hexo.theme.removeView(path);
        });
        watcher.on("addDir", (path) => loadDir(path));
    });

    const loadDir = (base) => {
        let dirs = readdirSync(base);
        dirs.forEach((path) => {
            const fullpath = resolve(base, path);
            const stats = statSync(fullpath);
            if (stats.isDirectory()) {
                loadDir(fullpath);
            } else if (stats.isFile()) {
                setView(fullpath);
            }
        });
    };

    loadDir(layoutDir);
});

到此主要功能以及实现了，其他待优化项这里就不描述了，可以看看完整实现源码。

使用示例 ​

以为 hexo-theme-async 为例，在根目录新建 layout 目录，再目录下添加 sidebar.ejs 文件，结构如下：

┌── blog
│   └── layout
│          └── sidebar.ejs
│   └── scaffolds
│   └── source
│   └── themes

sidebar.ejs 添加一点内容

<div>111</div>

在 _config.async.yml 中修改 layout 配置，替换掉默认 sidebar 模板。

layout:
    sidebar: async/sidebar

运行起来后，可以看到效果和 修改示例 中的效果一样，但是简化了用户使用。

结语 ​

通过上面方式，可以在使用 npm 安装主题时，也支持自定义替换部分区域，来个性化的目的，当主题版本迭代升级后，也更方便用户更新升级。

完整实现源码可以参考 hexo-theme-async 中源码。

随着前端发展的越来越工程化，越来越繁琐复杂，前端能做的事情越来越多，最近几年 前端基建 也是越来越火热。但是实际上很多公司并不注重前端，更别谈能会有人来做基建。对于没有基建的前端，我们能做些什么呢？

我个人推荐可以从工具、CLI 入手，因为这些往往是独立，不会像推规范、搞数据埋点、日志上报、整 BFF 那样对团队或者现有代码有入侵性。即便在自己空闲时间也能弄一弄，弄得好可以在团队推广使用，弄得不好也无所谓，可以当作练手提升自己能力。

什么是前端基建？ ​

前端基建 指的是业务团队内的前端工程师执行的一些基础建设，包括了 前端规范文档、前端脚手架、前端模板、前端组件库、前端工具库、前端 BFF、前端 CI/CD 的构建部署、前端数据埋点 等等；

前端基建的好处

• 业务复用；
• 提升研发效率；
• 规范研发流程；
• 团队技术提升；
• 开源建设；

善用工具解放双手 ​

举例：最近接到一个需求，一张简单报表包含增删改查，相信每个公司都有自己封装好的增删改查组件或者 hooks，等接口定义好，直接写 api，配好表单，表格配置完事。但后来接口发生变动，或者查询变动，这个时候就需要手动去调整原来代码。又或者做完这个后又来了个十几个报表需求，又得需要将上面来个十几遍。有些公司甚至连封装都没有，项目里全是 CTRL V + C，重复工作量更是陡增。

这些重复性操作完全可以通过工具自动生成，提交代码准确性，也能解放自己双手（摸点 🐟 不香吗），提高团队效率。

工具能做事情，做的东西有很多，不仅仅只是代码生成这些，一切你觉得重复性工作，都可以尝试通过工具来提高自己效率。

• 代码生成
• 代码格式检测
• 智能提示
• 测试自动化
• 文档集成
• 代码调试
• ...

工具实现方式有很多种，这取决在团队需求

• cli
• web （比如通过拖拉拽生成代码）
• 编辑器插件 （比如 vscode 插件）
• ...

重复代码生成 ​

就以上面例子为例，就可以使用工具去生成 接口的定义、表格配置、表单配置以及组件使用代码，不同需求表单、表格那些都是高度相似的，可以通过代码生成方式来提升自己编码效率。

从接口文档到可用代码，生成的方式大概流程如下：

接口文档 =》 JSON Schema =》 UI 交互（可省略）=》 根据模板生成 || 根据 AST 生成 =》 插入到代码位置

生成 JSON Schema ​

为了方便后续代码生成，我们需要首先接口文档转换成一个标准通用格式，这样不管后端提供什么样格式 api 文档或者不管后端使用什么框架去生成 api 文档时，只需要将对应格式转换成我们 JSON Schema 格式即可。

UI 交互 ​

UI 交互并不是必须的，比如生成 接口定义、类型定义 并不需要交互，直接生成就可以了。但是像表格生成、表单生成这些是需要的，因为接口返回字段并不一定全是需要生成的，可以通过添加适当交互完成这一步骤。

代码片段生成 ​

代码生成方式分两种 模板、AST 去生成。使用 模板 比较简单，也会比较直观，但是缺乏灵活性，使用 AST 会更为灵活，但也会复杂的多。

模板 ​

对于一些固定代码片段格式，可以选择通过模板去生成，而不必使用 AST 增加代码生成复杂度。

比如你项目中请求方法格式如下，可以直接使用模板去生成，类似这样 const {0} = (par) => http("{1}", par, "{2}");

const apiFn = (par) => http("/api/demo", par, "post");

AST ​

AST 是抽象语法树 (Abstract Syntax Tree) 的简称，它是源代码语法结构的一种抽象表示。它以树状的形式表现编程语言的语法结构，树上的每个节点都表示源代码中的一种结构。

当你生成代码需要根据不同条件生成不同节点，修改不固定时候，可以选择使用 AST 去生成。

AST 生成原理，简单来说说就是将代码生成一个树状结构，其中树中每个节点描述的应就是你实际代码，我们只需要根据需求去操作对应节点，然后再将 AST 转为代码。

不同工具生成 AST 是不一致的，可根据实际需求选择。在线查看 AST 结构工具，可以说很直观方便 ast explorer ts ast

插入代码位置 ​

将生成代码插入到现有代码中，实现方式也有多种不同方式，通过对于简单的结构可以通过正则匹配去替换，对于复杂的结构可以通过 AST 方式去修改插入，如果你是基于编辑器插件去做的，还可以通过获取编辑器光标位置、选中等等操作将代码插入到对于位置。

更方便的文档查阅方式 ​

很多公司使用的都是像 yapi、swagger 等那些开源文档管理平台，很多都是 web 在线的，当接口文档字段很多时，需要平凡的来回切换查阅，这样也是比较浪费时间的。可以通过编辑器插件形式集成到我们插件中，这样可以更方便自己开发，也有很多时以及有现成插件可以使用的，但是功能上并不丰富，有些仅仅只能查看，连常见代码都无法生成。

将接口文档集成到编辑器里能做的事情有很多，以 vscode 来说，可以通过文档快速生成接口定义，还可以通过注册语言服务，来识别检测接口定义正确性，也可以做的接口文档发生变更，做到智能提示然后快速自动修改，也可以通过接口文档快速起个 mock 服务，而不需要手动在项目中添加 mock 定义等等。

其他 ​

很多繁琐的事情，其实可以尝试通过工具简化这些操作，没有合适的可以尝试自己造个，既可以提升自己能力，又能给团队做一点贡献。

一句话总结就是，坑是真的多，填完一个坑等着你的就是下个坑。

缘起 ​

因为所在项目组属于生活服务类相关的，需要做电影、蛋糕、打车、加油、车票、酒店等一系列的板块，需要嵌入在其他项目的 app 、小程序、h5 中。我们需要提供 H5 和 小程序双端服务，由于每个项目周期又短，为了节省开发周期时间，所以选了 uni-app 来开发。

初识 ​

uni-app 使用上，基本上和普通 vue 开发差不多，只要避免直接使用 web api 就可以，捋一遍文档基本可以上手了。踩得的第一个坑来了，由于我入职时第一个板块已经开始做了，项目使用 HBuilderX 创建的。HBuilderX 创建的项目只能使用 HBuilderX 启动，HBuilderX 这东西也不好用，只能再开个 vscode 开发了，开发阶段也没觉得啥，无非多开发编辑器多占点内存。

等测试阶段傻眼了，HBuilderX 创建项目只能再 HBuilderX 构建发布，没法集成到现有 CI/CD 上去，再 HBuilderX 打包就打包吧，这玩意还强制登陆，一个编辑器不登陆还不让打包。搜索了一下，还是有方法将 HBuilderX 创建项目转换成 cli 形式的，不过由于项目模块导入方式混用，无法无痛切换过去，项目也快上线，于是就没有去折腾了，在下一个项目去切换到 cli 方式。

生态 ​

uni-app 有自己插件市场，有很多现成的插件可以用。但是呢当你去下载插件是骚操作来了，首先是强制需要你登陆，然后登陆后还需要你强制看广告才能下载，这波骚操作真的是骚。有些作者希望整点插件赚点外快，可以收费下载可以理解，但是别人免费开源的插件，uni-app 还强制你扫码看广告是真的恶心了。

uni-app 一直都在加新功能，对于 bug 处理速度真的是慢，官方论坛一大堆没人回复的问题，一个劲的堆新功能，bug 没见修复多少，bug 全留着当传家宝了。HBuilderX 也是有点离谱，第一次在开发者工具里边看到招聘广告的，只能说 newb 了。

踩坑 ​

定位 ​

在 H5 中 uni.getLocation，内部抛出异常，没做处理，导致无法捕获到，也不会进入 fail 回调，导致无法得知定位失败。比如 地图 key ip 定位超上限， navigator.geolocation 定位失败等。 ​

解决方式：

h5 端自己对 navigator.geolocation 封装，其他端使用 uni.getLocation。或者对 uni.getLocation 进行封装增加超时设置，超过几秒未返回，返回默认定位点。自己封装 navigator.geolocation 需要做好坐标转换，应该浏览器默认返回是 wgs84 ，需要自己转换为 gcj02 或其他的坐标系。

定时失败时候，只要你配置了地图 key，就会使用对应地图服务商 ip 定位。因为正常情况下前端的地图的 key 只需有地图绘制相关功能使用，不需要包含地图服务商 WebService API 功能的， 为了避免盗刷也不会将 WebService API 的 key 存放在前端，这就导致你使用 uni-app 的 map 组件，就会使用 ip 定位，但你的 key 并不支持。 ​

解决方式：

和上面处理方式一样，最直接就是自己封装 h5 定位，将 ip 定位地址，替换成自己服务器地址作为代理。

uni.openLocation 在 vue3 + ts 中，H5 端是以组件形式存在的，不想其他 vue2 是以路由形式存在，看内部实现并没有监听路由变化卸载组件，会导致通过浏览时返回上一页时，组件还是覆盖在页面上。 ​

解决方式：

自定义查看位置组件，在 H5 端替换掉 uni-app 的。

map 渲染问题 ​

uni-app 的 map 封装了一些覆盖物绘制属性。比如绘制多边形区域绘制，如果在地图绘制前就已经给 map 的 polygons 属性设置了数据，第一次打开页面不会生效。避免这种情况出现，需要在地图渲染后在设置这些数据，但是在 updated 事件触发后立即设置也会出现问题，这种情况在第一打开页面时生效，第二次进入时候会出现不生效情况，未找到出现这种问题原因。 ​

解决方式： updated 事件后，再加入定时器延迟执行绘制操作。

嵌套渲染 ​

有多个 v-for 嵌套渲染时候， 内层的 v-for 上的点击事件在小程序中无法触发。 ​

解决方式： 将部分 v-for 拆分成组件形式，避免页面上 v-for 嵌套过多。

其他 ​

组件差异性 ​

有些组件会在不同平台出现不同差异效果，需要你慢慢去踩坑填坑，一个个的趟过去。比如 popup 组件，小程序会出现滚动透传问题，而在 h5 上做了兼容处理，但是如果你打开后，未关闭直接跳转到新的页面，会导致新的页面无法滚动，需要在路由变化时关闭当前页面里的 popup 组件，这种问题真的是只能自己遇到一个填一个了。

文档混乱 ​

uni-app 做了很多平台封装保证 api 的一致性，但是还是会经常写着发现平台不支持，只能自己另辟蹊径。

结语 ​

由于没有 app 需求，不知道在 app 上坑多不多，据以前同事使用体验来看据说坑更多🤣。不过对于一些简单应用可以尝试使用，毕竟能一套代码构建多端还是能提升不少效率的。但是你的应用复杂起来，什么多端开发，提高效率，这玩意效率真的不一定能高到哪里去，还不如分开效率高.

还在手动 npm publish 发布 npm ？ 还在手动更新版本创建发布 Github Release ？还在手动添加 Changelog？是时候利用 CI/CD 解放双手啦。常见的 CI/CD 有很多，比如 Jenkins、GitLab CI、CircleCI 、Github Actions 等。本文主要是通过 Github Actions 来自动化处理 npm 包管理。

Github Actions ​

GitHub Actions 距离推出已经好几年了，相信小伙伴们没用过，也听说过。GitHub Actions 不仅仅是能自动执行生成、测试和部署操作，还允许您在存储库中发生其他事件时运行工作流程。 例如，您可以运行工作流程，以便在有人在您的存储库中创建新问题时自动添加相应的标签。而且 GitHub 提供 Linux、Windows 和 macOS 多种虚拟机来运行工作流程，可以更具项目选择合适的虚拟机环境。

GitHub Actions 其实主要步骤只有两个，event (事件触发时机)、jobs（工作流程）。如果还不熟悉 GitHub Actions，可以参考文档对其大致使用有个了解。

发布 Npm ​

在本地发布 npm 包都是本地打包成组件后，登录 npm 账号运行 npm publish 发布。使用 GitHub Actions 来发布 npm 可以使用 Npm Access Tokens，可以更据需要分配 Tokens 权限，不需要使用账号密码登录。

Github Actions 发布 Npm ​

首先需要确定你工作流触发时机，这个需要根据你个人习惯决定。

举例：

on:
  push:
    tags:
      - "v*"

on:
  push:
    branches: [master]

# 仅在 master 推送时，且 docs 下文件修改时触发，更多可以[参考文档](https://docs.github.com/zh/actions/using-workflows/events-that-trigger-workflows)
on:
  push:
    branches: [master]
    paths:
      - 'docs/**'

本文就以为推送 Tag 触发为例：

在你项目下添加 .github\workflows\publish.yml 文件，内容如下

name: NPM Publish
on:
  push:
    tags:
      - "v*"

代码拉取和Node配置 ​

在 jobs 添加一个名为 build 的 job，配置 build 的环境和拉取代码。runs-on: ubuntu-latest 配置虚拟机为 ubuntu，使用官方提取代码拉取和 配置 Node 的 Actions，更多 官方提供 Actions

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2   # 拉取代码
      - uses: actions/setup-node@v3 # 设置 Node 版本
        with:
          node-version: 16
          registry-url: 'https://registry.npmjs.org'
          cache: yarn

配置环境密钥 ​

添加环境变量，在你项目 => Settings => Secrets and variables => Actions 中 添加你的密钥，名称随意取，密钥值为你上面生成的 Npm Access Tokens。

例如： Name => NPM_TOKEN Secret => 你的 Npm Access Tokens

发布 Npm ​

build 的 job 中，添加发布 Npm 操作，利用 NPM_TOKEN 发布 npm 包

    steps:
      - name: Npm Publish
        run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

到此时，当你推送一个以 v开头 tag 到仓库时，就会执行这个 publish.yml，这个 Action 会将当前仓库发布到 Npm 了。

当然你的包可能还需要执行一些构建操作等等，你可以在 run 里执行多条命令

run: |
    npm run build
    #...更多操作
    npm publish

区分 Beta 和 latest ​

默认情况下 npm publish 发布时正式包，如果需要测试包需要执行 npm publish --tag beta。利用 git tag 我们可以将 v1.0.2 格式发为正式包，将 v1.0.2-beta.1 格式发布测试包。

修改 publish 流程，Github Action 支持 if 操作，并不支持 else，只能通过如下模拟 if else 操作。

    steps:
      - name: Beta Publish
        if: ${{ contains(github.ref,'beta') }}
        run: npm publish --tag beta
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

      - name: Publish
        if: ${{ !contains(github.ref,'beta') }}
        run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

根据 Tag 更新版本号 ​

为例避免每次修改 package.json 中版本，我们可以根据 tag 来修改 package.json 中版本，因为上面配置 node 环境，可以直接执行 node 代码，我们直接添加一个 publish.js 文件，去修改 package.json 中 version 。

const fs = require('fs')
const path = require('path')

if (process.env.RELEASE_VERSION) {
    const version = process.env.RELEASE_VERSION.split('/').reverse()[0]
    console.log('当前版本：', version);
    const pkg = require('./package.json')
    pkg.version = version.replace('v', '')
    fs.writeFileSync(path.resolve(__dirname, './package.json'), JSON.stringify(pkg, null, 4), 'utf-8')
}

修改 publish 流程，在发布前修改版本，并将 github.ref 添加环境变量 RELEASE_VERSION

    steps:
      - name: Build
        run: node ./publish
        env:
          RELEASE_VERSION: ${{ github.ref }}

创建发布 Github Release ​

官方 actions/create-release 不在维护，推荐如下 Actions，可以结合需要选择，你也可以去前往 marketplace 选择更多 Actions。

• elgohr/Github-Release-Action
• marvinpinto/action-automatic-releases
• softprops/action-gh-release
• ncipollo/release-action

很多创建 Release 的 Actions，并不会将你的提交自动生成发版说明，所以我编写了一个发布 Release 的 Actions，具体实现参考 MaLuns/add-release 以满足我的需求。Github 为我们提供 actions/toolkit 帮助我们简化了很多操作。

简单描述如何实现：

编写完自定义 Actions 后，使用自定义 Actions。

    steps:
      - name: Release
        uses: MaLuns/add-release@指定版本
        with:
          files: Demo.zip
          generate_by_commit: true

效果图：

到此，一个根据 Git tag 自动发布 Npm 和 Release 的工作流编写完成了。你还可以在结合 Github Pages、Vercel 等同时自动化部署你的 Npm 包的文档和示例站点等。

事情是这样的，我做了一个在线壁纸小程序，壁纸预览部分为了更好时使用体验，增加了类似于那些短视频上滑下滑快速切换壁纸预览的功能，为了避免重复造轮子直接使用了 swiper 来时实现滑动快速切换壁纸。

问题所在 ​

当壁纸量比较多的时候，全部渲染成 swiper-item，会出现明显性能问题。还有个原因应该预览壁纸时加载的都是高清原图，直接全部加载出来，对性能也是很大一个浪费。图片的加可以通过设置 lazy-load 懒加载图片。

解决方案 ​

解决方案也挺简单，直接使用分页去处理，比如有 200 项，但是我们一次只渲染 3 个 swiper-item，比如当前下标是 1（对应原列表下标1），当你下滑时新的下标就是 2（对应原列表下标2）了，这个时候就需要我们更新下标 0（对应原列表下标3），为当前项，对应原始列表中的下一个，上滑也是这样的逻辑，这样就保证每次滑洞都按照原始列表顺序显示的，但是实际页面只渲染 3 个 swiper-item，和虚拟列表原理类似。

官方提供了一个 video-swiper 组件，原理时类似的，只不过是给视频列表使用的，我们参考他的实现进行修改。

实现 ​

假设我们的数据的为 list，实际渲染的数据为 swiperList，我们现在给他就固定 3 个 swiper-item，前后滑动的时候去替换数据，正向滑动的时候去替换滑动后的下一个数据，反向滑动的时候去替换滑动后的上一个数据，然后将 swiper 设置为可衔接滑动，这样保证一直可以循环滑动，然后更具滑动方向替换数据。

监听 swiper 的 bindchange 事件，可以获取到滑动后的 current，然后在 bindchange 事件里更新数据

滑动的方向判断

// swiper 长度
const LEN = 3
const stateNum = current - this.data.swiperIndex
const state = [-1, LEN - 1].includes(stateNum) ? "Last" : "Next"

获取 swiperList 需要更新的下标

let updateIndex;
if (state === "Next") {
    updateIndex = current === (LEN - 1) ? 0 : current + 1
} else {
    updateIndex = current === 0 ? (LEN - 1) : current - 1
}

除了需要 swiperList 更新下标，还得记录对应 list 的下标

// 获取当前项对应 list 下标
const previewIndex = state === "Last" ? this.data.previewIndex - 1 : this.data.previewIndex + 1

然后据可以根据滑块方向和 previewIndex，就可以确定更新 swiperList 数据了

 this.setData({
    // 更新实际 list 下标
    previewIndex, 
    [`swiperList[${updateIndex}]`]: state === "Last" ? list[previewIndex - 1] : list[previewIndex + 1] 
})
// 记录 swiper 下标
this.data.swiperIndex = current

根据上面思路基本上可以解决 swiper 数据量大性能问题了，但是还存在一些问题。

• 滑块边界问题，list 数据也是有限的，也会滑到边界，需要对边界做一个判断处理

这个问题可以根据 previewIndex 下标去判断是否到达了边界，如果不需要无限加载数据，可以在达到边界时直接回弹静止滑块继续滚动，因为设置 swiper 为衔接滑动，达到边界时滑动时上一个或者下一个还是会显示有其他 swiper-item，所有需要我们添加一个空的 swiper-item 用来占位。如果时需要无限加载数据，可以在快到达边界时提前拉取数据，等拿到数据时继续下滑，否则反弹回去保持在最后一个。

• 当 previewIndex 不是通过滑块更新时候，比如直接从 0 跳到 5 会有默认滚动动画，导致体验很差

这个解决方式是在非滑动更新时候，先将动画时间 duration 设置为 0 ，去掉动画，然后在更新下标和恢复动画。

this.setData({ duration: 0 }, () => {
    this.setData({
        previewIndex: previewIndex,
        swiperIndex: swiperIndex,
        swiperList: swiperList,
        duration: 500
    })
})

代码实现 ​

相对完整的代码实现

<swiper vertical="{{true}}" duration="{{duration}}" current="{{swiperIndex}}" circular="{{circular}}" bindchange="handleChangeBigImage">
    <swiper-item wx:for="{{swiperList}}" wx:key="index">
        <block wx:if="{{item.type==='placeholder'}}">
            <view class="placeholder-view"></view>
        </block>
        <block wx:else>
            <image show-menu-by-longpress lazy-load mode="aspectFill" src="{{item.path}}"></image>
        </block>
    </swiper-item>
</swiper>

// swiper 长度
const LEN = 3
const SwiperPlaceholder = { type: "placeholder" }
type State = "Next" | "Last"

Component({
  properties: {
    list: {
      type: Array,
      value: [] as Array<ImageItem>
    },
    index: {
      type: Number,
      value: 0
    }
  },
  data: {
    // 当前元素下标
    previewIndex: 0,
    // swiper 切换
    circular: true,
    duration: 300,
    swiperIndex: 1, // 当前 swiper 下标
    swiperList: <Array<ImageItem>>[],
  },
  observers: {
    'index,list': function (index, list) {
      if (list.length && list[index]) {
        this._initSwiper(index, list)
      }
    },
  },
  methods: {
    // 切换 swiper
    handleChangeBigImage(e: WechatMiniprogram.SwiperChange) {
      const { current, source } = e.detail
      if (source !== "touch") return;

      const state = this._getSlideState(current, this.data.swiperIndex)
      const previewIndex = state === "Last" ? this.data.previewIndex - 1 : this.data.previewIndex + 1
      const currentItem = this.data.swiperList[current]

      // 到达了边界时，反弹回去
      if (currentItem.type === "placeholder") {
        this.setData({
          swiperIndex: this.data.swiperIndex
        })
        return
      }

      this.setData({
        previewIndex,
        [`swiperList[${this._updateUpdateIndex(current, state)}]`]: this._getUpdateSwiperItem(previewIndex, state),
      })

      this.data.swiperIndex = current
    },
    // 初始化 Swiper 模式
    _initSwiper(index: number, list: Array<ImageItem>, cb?: Function) {
      this.setData({ duration: 0 }, () => {
        let swiperIndex = 1
        let swiperList: Array<ImageItem> = []

        swiperList.push(list[index - 1] || SwiperPlaceholder)
        swiperList.push(list[index] || SwiperPlaceholder)
        swiperList.push(list[index + 1] || SwiperPlaceholder)

        this.setData({
          previewIndex: index,
          swiperIndex,
          swiperList,
          duration: 500,
          isHide: false
        }, () => {
          if (cb) cb()
        })
      })
    },
    // 获取滚动状态
    _getSlideState(current: number, lastCurrent: number): State {
      const state = current - lastCurrent
      return [-1, LEN - 1].includes(state) ? "Last" : "Next"
    },
    // 获取需要更新下标
    _updateUpdateIndex(current: number, type: State) {
      if (type === "Next") {
        return current === (LEN - 1) ? 0 : current + 1
      } else {
        return current === 0 ? (LEN - 1) : current - 1
      }
    },
    // 获取需要更新数据
    _getUpdateSwiperItem(index: number, type: State) {
      const list = this.data.list
      let item
      if (type === "Last") {
        item = list[index - 1]
      } else {
        item = list[index + 1]
      }
      // 到达边界时 返回填充元素
      if (!item) {
        item = SwiperPlaceholder
      }
      return item
    }
  }
})

各种壁纸app，壁纸小程序打开全是各种广告，太影响使用体验，自己整了个壁纸小程序，简单无广告🤣

附上小程序码：

壁了个纸

在纯静态网站里，有时候会动态更新某个区域往会选择 Pjax（swup、barba.js）去处理，他们都是使用 ajax 和 pushState 通过真正的永久链接，页面标题和后退按钮提供快速浏览体验。

但是实际使用中可能会遇到不同页面可能会需要加载不同插件处理，有些人可能会全量选择加载，这样会导致加载很多无用的脚本，有可能在用户关闭页面时都不一定会访问到，会很浪费资源。

解决思路 ​

首先想到的肯定是在请求到新的页面后，我们手动去比较当前 DOM 和 新 DOM 之间 script 标签的差异，手动给他插入到 body 里。

处理 Script ​

一般来说 JavaScript 脚本都是放在 body 后，避免阻塞页面渲染，假设我们页面脚本也都是在 body 后，并在 script 添加 [data-reload-script] 表明哪些是需要动态加载的。

首先我们直接获取到带有 [data-reload-script] 属性的 script 标签:

// NewHTML 为 新页面 HTML
const pageContent = NewHTML.replace('<body', '<div id="DynamicPluginBody"').replace('</body>', '</div>');
let element = document.createElement('div');
element.innerHTML = pageContent;
const children = element.querySelector('#DynamicPluginBody').querySelectorAll('script[data-reload-script]');

然后通过创建 script 标签插入到 body：

children.forEach(item => {
    const element = document.createElement('script');
    for (const { name, value } of arrayify(item.attributes)) {
        element.setAttribute(name, value);
    }
    element.textContent = item.textContent;
    element.setAttribute('async', 'false');
    document.body.insertBefore(element)
})

如果你的插件都是通过 script 引入，且不需要执行额外的 JavaScript 代码，只需要在 Pjax 钩子函数这样处理就可以了。

执行代码块 ​

实际很多插件不仅仅需要你引入，还需要你手动去初始化做一些操作的。我们可以通过 src 去判断是引入的脚本，还是代码块。

let scripts = Array.from(document.scripts)
let scriptCDN = []
let scriptBlock = []

children.forEach(item => {
    if (item.src)
        scripts.findIndex(s => s.src === item.src) < 0 && scriptCDN.push(item);
    else
        scriptBlock.push(item.innerText)
})

scriptCDN 继续通过上面方式插入到 body 里，然后通过 eval 或者 new Function 去执行 scriptBlock 。因为 scriptBlock 里的代码可能是会依赖 scriptCDN 里的插件的，所以需要在 scriptCDN 加载完成后在执行 scriptBlock 。

const loadScript = (item) => {
    return new Promise((resolve, reject) => {
        const element = document.createElement('script');
        for (const { name, value } of arrayify(item.attributes)) {
            element.setAttribute(name, value);
        }
        element.textContent = item.textContent;
        element.setAttribute('async', 'false');
        element.onload = resolve
        element.onerror = reject
        document.body.insertBefore(element)
    })
}

const runScriptBlock = (code) => {
    try {
        const func = new Function(code);
        func()
    } catch (error) {
        try {
            window.eval(code)
        } catch (error) {
        }
    }
}

Promise.all(scriptCDN.map(item => loadScript(item))).then(_ => {
    scriptBlock.forEach(code => {
        runScriptBlock(code)
    })
})

卸载插件 ​

按照上面思去处理之后，会存在一个问题。 比如：我们添加了一个 全局的 'resize' 事件的监听，在跳转其他页面时候我们需要移除这个监听事件。

这个时候我们需要对代码块的格式进行一个约束，比如像下面这样，在初次加载时执行 mount 里代码，页面卸载时执行 unmount 里代码。

<script data-reload-script>
    DynamicPlugin.add({
        // 页面加载时执行
        mount() {
            this.timer = setInterval(() => {
                document.getElementById('time').innerText = new Date().toString()
            }, 1000)
        },
        // 页面卸载时执行
        unmount() {
            window.clearInterval(this.timer)
            this.timer = null
        }
    })
</script>

DynamicPlugin 大致结构：

let cacheMount = []
let cacheUnMount = []
let context = {}

class DynamicPlugin {
    add(options) {
        if (isFunction(options))
            cacheMount.push(options)

        if (isPlainObject(options)) {
            let { mount, unmount } = options
            if (isFunction(mount))
                cacheMount.push(mount)
            if (isFunction(unmount))
                cacheUnMount.push(unmount)
        }

        // 执行当前页面加载钩子
        this.runMount()
    }

    runMount() {
        while (cacheMount.length) {
            let item = cacheMount.shift();
            item.call(context);
        }
    }

    runUnMount() {
        while (cacheUnMount.length) {
            let item = cacheUnMount.shift();
            item.call(context);
        }
    }
}

页面卸载时调用 DynamicPlugin.runUnMount()。

处理 Head ​

Head 部分处理来说相对比较简单，可以通过拿到新旧两个 Head，然后循环对比每个标签的 outerHTML，用来判断哪些比是需要新增的哪些是需要删除的。

结尾 ​

本文示例代码完整版本可以 参考这里

预览图

前提 ​

本主题为 Hexo 主题，请确保您对 Hexo 已有基本了解 。详请参见 Hexo 官网。

开始前，请确保您的 Hexo 初始化工作已经准备完成，请参考 Hexo 安装。本主题依赖于 Node 14.x 以上版本，请注意您本地 Node 环境。

主题安装 ​

进入您的 Hexo 博客根目录，执行如下命令，安装主题：

npm i hexo-theme-async@latest

yarn add hexo-theme-async@latest

如果您没有 ejs 与 less 的渲染器，请先安装：hexo-renderer-ejs 和 hexo-renderer-less。

npm install --save hexo-renderer-less hexo-renderer-ejs

yarn add -D hexo-renderer-less hexo-renderer-ejs

启用主题 ​

修改 Hexo 博客配置文件 _config.yml，到此运行起来就 Hexo-Theme-Async 主题就生效啦。

# 将主题设置为 hexo-theme-async
theme: async

关于主题配置修改，可以参考 hexo-theme-async 文档

演示视频 ​

• 安装
  • npm 安装演示
  • 下载到 themes 目录演示
• 配置
  • 常用配置演示
  • 主题自定义图标、自定义代码高亮演示
  • 随机封面、友链页、相册页面配置演示
• 运行源码
  • hexo-theme-async 源码运行演示
• 在线体验
  • stackblitz

安装示例视频，更多视频前往这里

之前一波搞没了免费额度，这次直接要回收以前开通免费版的资源了。搞成基础套餐+按量计费模式，直接最低39.9块一个月。用不起了，腾讯是真TM的狗。

超出基础后，价格比原来也翻了好多倍。 准备关了评论插件，换图床了，之前图床用的云存储，还不让整个文件下载，简直无语子了。

因为以前使用的评论插件存在很多 bug 和漏洞，但是也没啥人用，一直没有去修改，最近空闲时间比较多，所以准备对之前插件进行重构一番。原评论插件是使用原生 JS 编写 WebComponents 组件，感觉结构维护起来挺费力的(自己太菜)，决定使用 Vue3 构建 WebComponents 。

已支持功能 ​

• 支持回复
• 支持插入表情（可禁用）
• 支持 Ctrl + Enter 快捷回复
• 评论框内容实时保存草稿，刷新不会丢失
• 支持私密评论（可禁用）
• 隐私信息安全（通过云函数控制敏感字段（邮箱、IP、环境配置等）不会泄露）
• 支持人工审核模式
• 防 XSS 注入
• 支持限制每个 IP 每 10 分钟最多发表多少条评论
• 支持邮件提醒（访客和博主）, 可扩展三方通知方式
• 支持自定义“博主”标识文字
• 支持自定义通知邮件模板
• 支持自定义【昵称】【邮箱】【网址】必填 / 选填
• 支持自定义代码高亮主题
• 支持自定义配置主题 (使用css变量)
• 通过邮箱登录快捷回复管理
• 内嵌式管理面板，通过邮箱登录，可方便地查看评论、回复评论、删除评论、修改配置、站点统计信息

踩坑记录 ​

组件样式问题 ​

vue-loader 在 customElement 模式下，当使用子组件时候，并不会将子组件样式插入到 shadow-root 里，默认只有父组件的样式，需要我们自己处理下。参考这里

style和svg问题 ​

直接使用打包后都是默认插入到 dom 里的，而没有插入到 customElement 需要我们对这里插入的数据进行一些处理。css 可以配合使用 to-string-loader 在挂载时候手工插入，svg 处理方法也类似这样。

contenteditable 光标问题 ​

使用 contenteditable 作为输入框时，当需要插入表情或者粘贴文本到光标处时候，需要存储光标信息，但是在 Can I Use 上看到 ShadowRoot Api: getSelection 的兼容性，可以看到除了 chromium 其他几乎都是不支持的。

弹出层问题 ​

当在 customElement 里实现 Popover 组件，点击其他区域需要关闭弹出层时候，一般情况下我们都是判断当前点击事件触发对象 (target) 是不是我们 Popover 本身来决定我们是否关闭，但是当我们点击在 customElement 上时候 document 事件的 target 是自定义元素本身，不会到自定义元素内部去，所以我们需要在 customElement 和 document 都做一个监听。

跨 customElement 数据共享问题 ​

在评论插件里，com-a(评论组件) 和 com-b(评论管理组件) 是使用的两个 自定义元素，但我们在 com-a 登录后，在使用 com-b 也需要有登录状态，这时候我们可能需要共享登录信息。

如果我们是用 js 去编写 customElement 去共享数据是很麻烦的事，还好在 vue3 还是比较好解决的，可以使用 reactive 去实现一个简易 store 去共享数据，实现一个 customElement 修改数据多个地方同时修改。

示例

const store = {
    state: {
        // 用户
        user: reactive({
            data: null
        }),
    }
}

export default store

给 customElement 添加方法 ​

vue3 提供 defineCustomElement 是没有将可以将函数暴露到 customElement 上的，只能通过元素上的 _instance (vue创建 customElement 创建实例) 去调用，需要我们自己对 defineCustomElement 做下改造。参考这里

总结 ​

重构过程中，发现坑还是挺多的，还好大部分还是有解决方法的。重写服务端时候，发现腾讯云云开发的数据库文档还是挺坑的，一些 MongDB 操作在里面也没有，调试也很麻烦。