在使用 Vibe Coding 的过程中，Codex 应如何规范开发范式?

一句话：在 Vibe Coding 里，Codex 不应只是“写代码机器”，而应被规范成“按契约执行的工程代理（Engineering Agent）”。

1. 先定“角色边界”：Codex 负责产出，人类负责决策

把职责分清楚，效率会高很多：

• 人类负责：需求优先级、架构取舍、风险接受、上线决策
• Codex 负责：代码实现、重构建议、测试补全、文档更新、脚手架

原则：AI 可执行，关键决策必须可追溯到人。

2.用“任务契约”驱动每次生成（不要直接一句话让它开写）

每个任务都给 Codex 一个固定输入模板（像 mini-PRD）：

1. 目标（要解决什么问题）
2. 范围（做什么 / 不做什么）
3. 输入输出契约（API、类型、错误码）
4. 约束（性能、安全、兼容性、依赖限制）
5. 验收标准（可测试、可观测、可回滚）
6. 交付物（代码 + 测试 + 文档 + 迁移脚本）

3. 强制“先设计后编码”

要求 Codex 每次先给：

• 方案摘要（2~3 种，含 trade-off）
• 选型理由
• 影响面清单（模块、接口、数据结构）
• 风险与回滚策略

通过后再开始写代码。

这一步能显著减少“看起来能跑但不可维护”的代码。

4. 开发流程标准化（建议 6 步）

1. Plan：Codex 输出实施计划（文件级变更列表）
2. Scaffold：先生成接口 / 类型 / 测试骨架
3. Implement：分小步提交（每步可运行）
4. Verify：单测、集成测试、lint、类型检查
5. Explain：生成变更说明 + 风险点 + 使用示例
6. Review Gate：人类审批后合并

5. 代码质量“硬门槛”（不可协商）

给 Codex 明确以下 gate，没过就不算完成：

• ✅ lint / format 全绿
• ✅ 类型检查全绿（TS / pyright / mypy 等）
• ✅ 关键路径测试覆盖达标
• ✅ 无高危安全问题（注入、密钥泄漏、越权）
• ✅ 性能回归可解释（基线对比）

6. 提示词（Prompt）规范：固定结构，减少随机性

建议团队统一 Prompt 模板：

• 背景与目标
• 当前代码上下文
• 技术约束
• 输出格式（必须含：代码、测试、迁移、文档）
• 禁止事项（如“禁止修改公共接口”“禁止引入新依赖”）
• 验收命令（例如 npm test && npm run lint）

7. 文档与可追溯性

要求 Codex 每次变更同步输出：

• CHANGELOG 条目
• ADR（重要架构决策记录）
• 接口文档更新
• 回滚指南

没有文档的 AI 代码，长期一定会变成维护负担。

8. 常见反模式（要避免）

• ❌ 让 Codex 一次性“重写整个模块”
• ❌ 没有测试就合并
• ❌ 只看“能跑”，不看边界条件和失败路径
• ❌ 让 AI 自行决定需求边界
• ❌ 不做 code review 就上线

9.可直接执行的团队规则（简版）

你可以把下面作为团队规范：

“所有 Codex 任务必须先有任务契约；所有生成代码必须附带测试与变更说明；所有高风险改动必须有人审；未通过质量 gate 禁止合并。”

如果你愿意，我可以进一步给你一份可直接粘贴到团队 Wiki 的《Vibe Coding + Codex 开发规范模板》（包含 Prompt 模板、PR 模板、验收清单）。

podman

这里有一个前提，我刚开始看的时候没有留意，导致查了好多资料，最后看大家都一样的写法，最后才发现了别人博客里面最开始就写了一句话: 如果*/etc/docker/daemon.json**这个文件有就直接改，如果没有就新增一个。*

// vim /etc/docker/daemon.json

{
  "registry-mirrors": [
    "https://docker.m.daocloud.io"
  ]
}

docker run

docker run -d -P m.daocloud.io/docker.io/library/镜像名称

样例:
docker run -d -P m.daocloud.io/docker.io/library/mongo

除此之外，还有另一种方法，直接用docker把容器跑起来，在镜像前面把代理的域名加上去就可以了。我就是没有把podman的代理问题解决，改用了这种方式，可以快速搞定。

在github上面找到了一个收集代理源[仓库public-image-mirror](https://github.com/DaoCloud/public-image-mirror)

前面几个月一直在学习bebal、eslint这种AST相关的知识，一直没有时间去写一篇正儿八经的博客，刚好体验了一下vitepress，在这里记录一下我是如何使用vitepress将我的知识仓库blog做成wiki的。

先展示一下我的文件目录结构，所有文件全部放在docs目录下，例如AST、Koa和工作周报这种比较特殊的文件夹是以关键字命名，剩余的博客全部是以年份，年份-月份，年份-月份-博客标题方式命名。

在vitepress的环境中，可以直接指定其工作目录为docs这样我们就可以快速地搭建出项目的基本目录。至于如何使用vitepress大家可以快速移步至vitepress的官网。在这里不做过多的介绍，浪费大家太多的时间，使用的步骤非常简单。

下面列出大家可能需要解决的问题:

1. vitepress不会自动生成菜单和导航，需要你自己维护
2. vitepress采用约定式路由，文件路径即为路由地址
3. 分组维护菜单时必须保证其键值与路由匹配
4. 配合github actoins自动构建发布wiki

一、如何自动生成菜单

为了处理上述的问题一与问题二，我们必须先认识一下vitepress的配置文件。在我们执行vitepress的init指令后，会在工作目录下生成index.md文件与**.vitepress**目录。

其中，index.md文件就是项目的首页，在这个页面中可以维护这个网站的快捷入口、标题、描述，具体的就是下面这个样式，这个模板就是vitepress提供的默认模板。

---
# https://vitepress.dev/reference/default-theme-home-page
layout: home

hero:
  name: "shadow's wiki"
  text: "Fragmented knowledge manager"
  tagline: 碎片化知识管理库
  image: https://user-images.githubusercontent.com/34117238/117454439-b7d41d00-af78-11eb-8b6f-7e4be67d9aa8.jpeg
  actions:
    - theme: brand
      text: 主站点 - wuh.site
      link: https://wuh.site
    - theme: alt
      text: 开放API - api.wuh.site
      link: https://api.wuh.site/v2
    - theme: alt
      text: 文档站点 - docs.wuh.site
      link: https://docs.wuh.site

features:
  - title: 搬山计划
    icon: { src: 'https://user-images.githubusercontent.com/34117238/117454439-b7d41d00-af78-11eb-8b6f-7e4be67d9aa8.jpeg', width: '120px', height: '120px' }
    details: 自我修养,犹如搬山
    link: /$blog/2021/2021-05/搬山计划.html
  - title: 2022年度总结
    details: 每年年中发布一次的年度总结
    icon: { src: 'https://src.wuh.site/2022-02/2022-02-08-124302.png', width: '120px', height: '120px' }
    link: /$blog/2022/2022-01/2022年度总结.html
  - title: 进取
    icon: { src: 'https://src.wuh.site/2022-09/20220901.001.png', width: '120px', height: '120px' }
    details: 静以修身，俭以养德。勿以善小而不为，勿以恶小而为之。
    link: /$blog/2022/2022-09/进取.html
---

另外，在**.vitepress中存在一个config.mjs**文件，它就是整个项目的配置文件了，下面是我的配置文件：

import { defineConfig } from 'vitepress'
import navGenerator from '../../plugins/nav-ganerator'

// https://vitepress.dev/reference/site-config
export default defineConfig({
  title: "shadow's wiki",
  description: "Fragmented knowledge manager",
  titleTemplate: '吴尒红',
  head: [
    ['link', { rel: 'icon', href: 'https://wuh.site/_next/image?url=%2Ficons%2F64.png&w=64&q=75' }],
    [
      'script',
      { async: '', src: 'https://www.googletagmanager.com/gtag/js?id=G-X4ZVBQXW9E' }
    ],
    [
      'script',
      {},
      `window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      gtag('js', new Date());
      gtag('config', 'G-X4ZVBQXW9E');`
    ]
  ],
  themeConfig: {
    // https://vitepress.dev/reference/default-theme-config
    nav: [
      { text: '首页', link: '/' }
    ],

    sidebar: {},

    socialLinks: [
      { icon: 'github', link: 'https://github.com/stack-wuh/blog/tree/gh-page' },
      { icon: 'twitter', link: 'https://twitter.com/wuh131420' }
    ],

    footer: {
      message: 'MIT License.',
      copyright: 'Copyright ©2023. shadow'
    },

    editLink: {
      text: '去github编辑',
      pattern: 'https://github.com/stack-wuh/blog/blob/master/docs/:path'
    },

    lastUpdatedText: '最后更新于',
    lastUpdated: true,

    search: {
      provider: 'local'
    },

    outline: {
      level: [2, 3]
    },

    logo: {
      src: 'https://wuh.site/_next/image?url=%2Ficons%2F64.png&w=64&q=75'
    }
  },
  vite: {
    plugins: [navGenerator()]
  },
  markdown: {
  },
  sitemap: {
    hostname: 'https://wuh.site'
  },
  rewrites: {
    '([0-9]{4})/(.*)': '$blog/([0-9]{4})/(.*)'
  },
  outDir: 'wiki.wuh.site',
  srcExclude: ['**/README.md', '**/*.js', '**/*.png', '**/*.assets'],
  metaChunk: true,
  base: '/blog/',
  ignoreDeadLinks: true
})

如果不出意外的话，在你执行pnpm init以及 pnpm dev之后，会出现由vitepress提供的默认页面。但是你的工作目录下的文件并没有自动生成菜单。

现在我们回到刚刚开始的问题，如何自动生成菜单和导航？

有两种方法，第一种是常规方法，把路由一个个在themeConfig.sidebar中维护进去，还有一种是利用其编译时的能力，写一个vite插件，直接在编译时改掉vite上下文中的配置文件。

大家回到config.mjs文件中，仔细看一下我在vite中配置了一个插件navGenerator。在这个插件中我们只需要将文件路径转化为路由地址就可以了，然后在vite的上下文中的themeConfig.sidebar 改写为我们重新生成的对象就可以了。

const navGenerator = () => {
  return {
    name: 'nav-generator',
    configResolved(config) {
      const { vitepress } = config
      if (!vitepress) return
      const menus = slideGroupByHead(vitepress.pages)

      Reflect.deleteProperty(menus, '序言')
      vitepress.userConfig.themeConfig.sidebar = menus
      vitepress.userConfig.themeConfig.nav = transformToNav(menus)
    }
  }
}

vite中的插件开发极其简单，利用vite提供的能力在其对应的钩子中，直接改其上下文的对象，就可以满足我们的需求。

我在刚开始做的时候也去找了一些博客看了一下前人是怎么做的，后来我发现他们的做法有点没必要。他们在利用vite的钩子在生成正常的路由地址后，去改写了config.mjs源文件中的sidebar对象，可实际上完全没有必要。

无论是webpack还是vite它们的构建流程都是链式的，它代表着上一个插件如果改动了上下文中的配置是会影响下一个插件的。所以完全不用去改源文件，只需要改动钩子中暴露出来的vitepress context，就可以满足需求。

但是有一个大前提，这个过程必须发生在最终生成文件的的插件之前。我们已知vitepress将md文件转换成html是利用的markdown-it插件，所以必须将navGenerator插件的触发时间提前。

正好configResolved钩子是最前面的那个入口，而且在此时vitepress已经完成了目录的解析，在此时我们已经可以非常完整地拿到工作目录下全部的md文件了。

插件的全部代码可以点击链接在github中的plugins/nav-generator查看。

二、如何正确维护多分组sidebar

但是分组多侧边栏这里有一个小坑要注意一下。

以我的项目文档为例，最后生成的文档对应的对象应该是下面这样，我只截取一部分展示。

与生成sidebar同理，nav的数据也可以继续利用这种方法生成。最后的效果就是大家看到的封面图那样。

三、自动构建发布

继续利用我们之前介绍过的github actions帮助我们自动构建发布。同样在vitepress的官网中提供的一个工作流示例。

github actions是一个非常友好的工作流，在之前我已经写了一篇博客，详细地介绍了我是如何actions实现了我的博客项目自动构建发布，可以移步原文Github Actions 自动部署应用。

下面是我的工作流配置文件:

# 构建 VitePress 站点并将其部署到 GitHub Pages 的示例工作流程
#
name: Deploy VitePress site to Pages

on:
  # 在针对 `main` 分支的推送上运行。如果你
  # 使用 `master` 分支作为默认分支，请将其更改为 `master`
  push:
    branches: [gh-page]

  # 允许你从 Actions 选项卡手动运行此工作流程
  workflow_dispatch:

# 设置 GITHUB_TOKEN 的权限，以允许部署到 GitHub Pages
permissions:
  contents: read
  pages: write
  id-token: write

# 只允许同时进行一次部署，跳过正在运行和最新队列之间的运行队列
# 但是，不要取消正在进行的运行，因为我们希望允许这些生产部署完成
concurrency:
  group: pages
  cancel-in-progress: false

jobs:
  # 构建工作
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # 如果未启用 lastUpdated，则不需要
      - uses: pnpm/action-setup@v3 # 如果使用 pnpm，请取消注释
        with:
          version: 8
      # - uses: oven-sh/setup-bun@v1 # 如果使用 Bun，请取消注释
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: pnpm # 或 pnpm / yarn
      - name: Setup Pages
        uses: actions/configure-pages@v4
      - name: Install dependencies
        run: pnpm install # 或 pnpm install / yarn install / bun install
      - name: Build with VitePress
        run: pnpm run docs:build # 或 pnpm docs:build / yarn docs:build / bun run docs:build
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: docs/wiki.wuh.site

  # 部署工作
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    needs: build
    runs-on: ubuntu-latest
    name: Deploy
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

在使用vitepress搭建wiki库之前，先切一个gh-page分支出来，后期我们做自动构建主要是以这个分支为主，而不是master分支。

注意，我们只需要改几处就可以使github正常工作了:

1. 构建分支，将其改为gh-page
2. 将打包器改为使用pnpm
3. 将指令也改为pnpm配套指令
4. 更改产出文件目录

与此同时，项目内部的config.mjs文件产出目录也需要改一下，因为github pages的部署路由会自动在前面加上/blog/，所以项目的basePath也需要加一个前缀/blog/。

到此为止，全部的流程就介绍完啦~~~

昨天下了一天的雨，闲着实在没什么事情做，就在微信阅读里面找了一本书《长安的荔枝》来读，读的正在兴头上呢，结果出现了下面这个恶心的东西。不得不说，现在的微信读书没有之前好用了，腾讯总是习惯于把一款优秀的产品做成垃圾。

实在是受不了这种，我是提倡知识付费的，但是白嫖还是快乐的。我想起了之前看到的一个视频里面提到过一个免费的在线图书馆，资源贼拉多，它就是大名鼎鼎的zlibrary

这个网站的官网已经被封了，一些镜像站也被封了。我是在telegram里面找到了一些组群，在里面找到了一个可以使用的机器人：https://t.me/fbooki

这个机器人会发一些可以使用链接地址，大家可以自行点击使用。下面我贴一个镜像站：https://lib-boxnfxb7fl57xmwt2nd5h4gx.1lib.fr/。

除此之外，还有一种的暗网访问的方法，这里贴一个教程链接:https://www.youtube.com/watch?v=pK3LzbT271E

其使用方式是一样一样的，点击书籍链接进入明细就可以看到下载按钮了，我们直接使用默认的下载类型，然后在微信读书里面导入本地文件，就也可以继续阅读了。

注意:

1. 使用zlibrary有一个大前提，准备好科学上网

在项目中，经常会遇到的一种情况，就是大段大段的逻辑代码，各种各样的逻辑全局集中到了主函数的内部，在上一次的【盘活运力】的review中，我给大家描述了一下，我是怎么处理大段逻辑代码的，这里是记录性质的博客。

对于可复用性要求较高的公共函数、公共文件的封装或者是逻辑的处理。可以对比去看一下重构之前的代码，大段的逻辑代码集中在一个函数内部，导致一个函数的逻辑杂糅，一个方法甚至有几百行，这都是需要优化的地方。

从我个人的经验来看，对于公共方法，有以下几个关键点:
高灵活性
高区块性
高责任性

高灵活性
其实，灵活性就是可扩展性。

我们在写公共的函数的时候，无论是mixin文件还是utils工具文件，都要做到的一点就是，一定要操作空间，一旦这个函数内部的逻辑不满足了，还可以通过外部传入的逻辑，来实现我的最终目的，而不用改动公共函数的内部代码。

怎么留足操作空间呢？就是在关键的逻辑位置提供一个函数，可以满足外部传入的需求。

高区块性
区块性，就是说将一大段函数逻辑，拆分为若干个逻辑片段。

既然是逻辑杂糅了，那就必然可以将一段杂糅的逻辑切片成多段逻辑，然后按照执行的顺序依次执行，到了最后的结果就是将多段函数的执行结果就是大函数的执行结果，这种方法就叫分治。

高责任性
指函数职责的单一性要强，对于公共函数一定要做到，一个方法一个功能。

对于单一职责我们一直放在嘴边，但是完成的力度一直不够，我们可以回想一下现在的代码，很多情景下，对于多个地方用到了相同的公共函数的位置，经常会来新声明一个函数。而这个新函数的作用就是将多个公共函数放在一起，然后在页面上就调用这个新函数。

对于这个新函数，你能说它职责单一了吗？

一旦遇到了特殊场景，大部分开发人员就会在新函数内部，使用各种if/else的逻辑判断来执行对应的函数，随着迭代次数越来越多，逻辑越来越复杂，新函数就成了另一个杂糅函数，换一句话说，它不纯了。

分治法
分治法，是一种经典的数学算法，取分而治之之意。目的是将一个复杂的问题划分为多个相同或者是相似的小问题，分开解决。

对于具体实现可以看下图代码，文件地址：

这一段是我们经常遇到的处理表格的请求逻辑，它是一个非常典型的、可复用性要求较高的、可分治的案例。

它是一个mixin混入文件，给9个表格业务组件提供了全部的逻辑支持，基本没有出现什么问题。分治点已经标出，大家可以点击文件链接进去自由查看细节。

大家可以仔细看一下，上面说的三点在这个案例中已经全部体现出来了。

对于一个区块内部的逻辑，可以将它分成两块，一部分由函数体内部提供一个默认函数，同时支持外部传入函数，留足了操作空间，灵活性极佳。

每一个区块内部的函数，只管理它负责部分的功能，可以清晰的看到我标出的5个分治点，就是其区块性最好的体现。

现在项目中有大量的业务代码，可以提供给大家练手的机会，可以尽情地去使用分治法。

现在ERP以及支持通过Element面板查找使用组件的文件地址，但是还有一种情景是比较特殊的。在批量改完cooHttp优化需求之后，还可以通过发起的ajax的请求来查找发起请求的文件路径。

如下图，即为ERP支持的使用组件的文件地址:

如何通过ajax反查调用文件位置
打开NewWork面板中的Initiator栏

鼠标移入对应的接口处，就可以看到请求的执行栈，标红处是依次触发的方法，标蓝处是执行方法时对应的文件位置

吾日三省吾身，为人谋而不忠乎？与朋友交而不信乎？传不习乎？

最近，准确地说是昨天，发生了一件值得让我深思的事情。“我并没有学会珍惜”是我思考之后得出的结果。

我想我必须把这件事情记录一下，留给未来的自己，值得反复体会。

回忆

首先我家没什么底子，就是一个普普通通的农民家庭，从小到大没什么依仗都是靠我爸一个人独立奋斗，唯二的就是我的亲人们时不时地帮助，什么帮助呢？帮你做一做耗时的农活。

棉花，一种经济作物，但是现在它越来越廉价。

种棉花是体力活，它不像插秧苗直接插到水地里，唯一的相同点就是人必须得弯着腰，直到把家里的棉花田里全部种满，那个时候人才能得到一点点的休息时间。

有一种棉是开心棉，很好摘。还有一种，是闭口的，是淋了雨，打了风，掉落在地里的。这种不好搞，要暴晒之后，才能剥开外壳。

我印象中最深刻的画面就是我爸一个人，一台电视机，两大筐闭口棉，干到半夜1点过，而明天他早上5点又要早起下地了。

太阳，太炽热了，太残酷了，太无情了。

我能体会到，那段时间，准确地说是那十年，他很累。

现在，他在工厂里面上班，他终于脱离了面朝黄土背朝天的日子。

虚无的狂欢

我陷入了一种虚无，精神上的虚无。整整一个月的迟到，扣了2000块。刚开始我觉得没什么，就这样，它只是我工资的一小部分，更何况那段时间我确实感觉很累很累，早上睡不醒，晚上睡不着，头痛胃痛啥都有。

想吃啥吃啥，想买啥买啥，美其名曰太累，身体不好，需要搞点好东西改善一下伙食，现在回过头去看，简直是浪费，我忘记了过去的我了，我忘记了那一段艰苦的日子。

我很久没有读书了，最近沉迷上了王者荣耀，连胜让我觉得很过瘾，吸引我一直打下去。唯一让我欣慰地是，我没有染上一些陋习。

不赌不嫖不偷不抢，我还是我。迷失的是那个积极进取、热爱读书的我，我已经不再是我了。

我可以把一些客观因素归结到繁重的工作吗？是天天加班导致的心力交瘁？还是自己已经甘于沉沦了，甘愿躲在过去的阴影里面？

求己

我忘记了我们小学时候学过的《论语》了，还记得“吾日三省吾身”吗？还记得《劝学》吗？

我怎么可以把一切问题推给外部环境，我忘记了“适者生存”的丛林法则。如果我一直抱着这种想法，我终将被社会淘汰，成为优秀的猎食者的晚餐。

我突然之间想起了《人间失格》，自我催眠的弱者，怎么可能在这个社会丛林正常的生存。如果能在一些文学作品中看到自己的样子，说明这本小说是一个最基础的社会缩影，它是现实的。

试着通过这类文学作品去反推，看看自己在小说中的结局，它又是魔幻的。

魔幻的现实是残酷的，是悲剧的，是无法挣脱的枷锁，是禁锢自己的牢笼。

不去主动地打破牢笼，就失去了向上的阶梯， 将被永远的困在地牢，不见光明。失去了阳光，失去了一切。

我想起了刚上班的那段时间，上下班的路上我在思考怎么写那些业务代码，因为我接手的第一个项目就做砸了，当时是我的领导保了我，给了我第二次机会。那真是一段令人无法忘记的回忆。

变化

我觉得思考的东西应该是要深刻的。写到这里我想先停一下。

越是深刻的东西越是简单。归根究底，就是我进入社会的这5年，过的太顺利了。顺利到我还没有学会珍惜。

回顾了一下我的履历，我是在大佬的爱护下成长的。我的每一位领导年龄都比我大，我想他们对我的这种爱护之情，包容之心和同事之谊，就是我成长的养分。

我听说，我的同事们私底下对我的评价还不错，他们都认为我的业务水平还可以，但其实我已经在原地踏步了一年，我想我已经很落后了。

技术是个很容易替代的东西。我认为，一个刚毕业的大学生，给他足够的训练时间，外加一位负责的领导指导一下，可以极大地减少他上手的代价。

所以，遇到了这样的一个领导或者是同事，他又愿意和你交流，愿意给你分析一些问题，是一件幸福的事情，是一件值得珍惜的事情。同时，这样的同事是值得深交的，很多事情，有高人指点可以免去你很多的时间。

同时，在自己力所能及的范围内，对后浪们也要有一种爱护之情。他们只是比我入行晚而已，我的优势只是比他们提前入行，见过的东西多一些，见过套路多一些，除此以外，我没有任何优势。

启程

无言是最好的告白。

勿忧勿忧，欲说还休；不休不休，至死方休。

此刻，我一边喝着酒，一边想着一些骚话。

先来一口，开摆。

也不知道为什么起了这样一个标题，可能是忽然之间想起来这么一本书，内容是什么一时之间也想不起更多了。既然内容想不起来了，那就直接用他的标题吧。

如果非要给未来定义一个颜色，那我的未来一定是灰色，或者我认为我的未来是灰色。矛盾的对立统一在我的身上得到了相当明显的体现，换一种描述，那就叫它“纠缠”吧，再也不用纠结它的实体了，它就是抽象的存在。

我的生活轨迹就像是齿轮一样，每天都在重复做一样的事情，我很想改变他，最后却发现我无能为力，能改变的只能是我自己。

就这样，我在生活的漩涡中越陷越深。同时，我很庆幸我还没有结婚，还没有孩子，还没有家庭，还没有那如山的压力。我毫不怀疑，我可以想象出这样的一种压力可以把一个家庭家长的腰彻底压垮。

我已在漩涡中，挣扎太久，我变老了，我想我快失去动力了。

不要停步不前，每一天都要做出一点改变。

在开始分析之前，我想是不是需要一些数据模型来判断，在2021-2022年度我的个人发展是曲折向前的呢，还是原地踏步呢？

回头一想，还是算了吧。没有必要这么卷自己了，下面的数据留给阅读者自己对比吧。

阅读不是打发时间的一种消遣

书本之外的世界很大，书本之内的乾坤也不小。

现在，我不爱和人谈论的内容之一就是: ”你最爱看什么的类型的小说“，那没有意义。

和去年一样的套路，还是先列出今年的书单吧：

1. 这个女人不寻常呀! -- 《两京十五日》
2. 有的时候一本书名就是一段故事 -- 《西线无战事》
3. 有很多人喜欢项羽，也有很多人喜欢刘邦，我不一样，我喜欢曹操~~ -- 《楚汉双雄》
4. 三等、三惹的韵脚诗美如画，一如中国画的留白是留给观者的遐想，它的意境无边 --《天青色等烟雨》
5. 《三国演义》是中国的，也是世界的，更是小日本学不会的~~ --《银河英雄传说》
6. 狄仁杰的魅力，吸引了老外创作了这一系列的案件故事，尽管后面我看不太下去了 --《大唐狄公传》
7. 完全放弃了，不看了 --《剑来》
8. 孤独是自己最大的敌人吗？或许没有希望才是！--《一个叫欧维的男人决定去死》
9. 我记得之前的系列原名是叫“谋杀官员”，在两年之前我很喜欢看，这次是重温。 --《高智商犯罪》
10. 敲了一段话还是删除了，算了，他们是历史 --《五代十国的枭雄们》
11. 等待与希望 --《基督山伯爵》
12. 一半是吃人恶魔，一半是救赎神明，我应该怎么说呢，还是大家自己去看吧。 --《沉默的羔羊》
13. 我看了后记才知道，这一部小说的诞生前后经过了四十年，小半个世纪打磨出来的故事集确实比《后续》看起来更有感觉，更精彩。 --《夜谭十记》

人的耐心是有上限的，每一个人的上限都会不一样，甚至于每一个人在不同的时期面对相同的事情，其承受度都是弹性的，比如我对《剑来》的耐心已经消磨完了，越来越看不下去了。作者对其热门IP产品的消费是不是也要考虑一下读者的想法呀。

我喜欢古龙小说，他对笔下的大侠们战斗方式和战斗场景的描写极其简洁，往往几十个字就描述了一段精彩的战斗或者是前文铺下的伏笔，最后揭露出来让人大呼过瘾，只叫痛快。武侠小说和这种玄幻小说又有什么差异呢？这么多年过去了，我们仍然爱着古龙，和他笔下的那些大侠。

《基督山伯爵》是本年度内耗时最长的小说。不得不说作者设计的一些场景起承转合，尤其是终章善有善报的结局，当然最让人受不了的是那种不缺钱的“钞能力”。

等待和希望就是基督山伯爵一生的写照，他的上半生经历了被人陷害入狱，陷入了无尽的黑暗与等待之中。出狱后获得宝藏，在逍遥与复仇之间抉择，当然最后的结局是他复仇成功，那他呢？在复仇过程中，他的得与失孰多孰少呢？他失去的是那一个青春与活力的少年之心，在谋划复仇的过程中已经不复存在了。那他得到的呢？

所以他的上半生的关键字就是等待。

伯爵是一个善良的人，他宽恕了他的敌人，他原谅了背叛了他的恋人，他挽救了另一对陷入热恋的男女，同时他也拯救了自己。他不敢想一个高高在上的公主居然爱上了自己，当他带着公主乘帆远航，又回到了无边无垠的大海时，他在上半生失去的，在下半生重新得到了。人世间最幸福的事情莫过于失而复得。

所以他的下半生的关键字就是希望。

朋友们不要失去希望。

我发现日本特别喜欢三国题材，不信你去看一看《银河英雄传说》。其故事架构计划和《三国演义》一毛一样，不同的是，其故事时代在未来，将战场嫁接到了太空。

刚开始我想看一看他能写出什么不一样的故事，现在一看，还是别了吧。看《三国演义》更加的原滋原味。

我在看电视剧”一计害三贤“时，看到了一条弹幕，汉大将军起于卫青而终于姜维，姜维别号“天水麒麟”。多酷啊！！！

而在姜维出场之前，那么多的风流人物，俱往矣！

我在回乡的途中读完了《夜谭十记》的前五篇，在返程途中读完了后五篇。是巧合还是有意为之？我说不清了。

一群科员，一群无所事事的科员，一群喜欢乱扯谈的无所事事的科员，一群喜欢乱扯谈的无所事事的坐冷板凳的科员，最后留下了十记。

他们是那一个时代的缩影，流水的官老爷，铁打的科员，一成不变的是底层的劳苦大众。

峨眉山人，羌江钓徒，三家村夫，无是楼主，不第秀才，山城走卒，巴陵野老，穷通道士，野狐禅师，砚耕斋主，我还记得的这些科员的雅号，仿佛我也身在其中，他们带着令人心酸的往事，迎面走进屋来。

各位，容我先泡上一壶茶，再摆上几条板凳。来吧，开摆。

一撇一捺之谓道

“搬山计划”一直在继续，但是执行地断断续续。

我越来越喜欢写字，但是字一直写得不好看，以前信笺上的开头都写一句“见字如面”，如果我给一些朋友写信，那他们一定看不下去。

我知道字的结构要合理了，字才好看。用笔的力与势要中庸协调了，字的结构就合理了。但是我却不得入其门，我反思得出结果，其一练得少，其二路子野，其三任意潇洒，不循其法，不得其势，其四我再也没有那么多的精力了。

过刚者易折，善柔者不败。

“搬山计划”的最终目的就是训练自己，以中正平和为目标，磨练自己的冲动随性。半年多过去了，我个人认为还是得到了一些矫正。

一阴一阳之谓道，典出《易经》。我仔细地回味了一下，决定随意发挥一下，一撇一捺之谓道，以合方寸之间。

动与静两种态，就好比是阴与阳。互相成就，互相印证，此消彼长。

在自我磨练的过程中，我的“动”态慢慢地被消磨掉了，我的熵变低了，变得相对稳定了，换一句话说，我变得成熟了。

今年，我27岁了，我还很年轻，还有很多人没有遇见，很多事情没有经历。或许在不久的将来，我会选择冲冠一怒，也会选择沉默不言。

这是合理的，人不可能永远是被理性武装的动物，“动”和“静”就是一种动态的，互相侵略和互相抵御的过程。我甚至认为理性都是动态存在的状态，时间的不同，空间的不同，场景的不同，都是影响调整状态的元素。

用到了哪些新玩意

redux家族中又多了一个新朋友，rematch。结构与dva相似，打算在三月份做一个音乐播放页面，与网页顶部的播放器控件联动。

express阵营中也多了一个新朋友，nest。号称是nodejs化的spring boot，用了一下确实很简单，让我想起了很久之前的用过的angular，写起来很爽。

简单的玩了一下AST转换，玩的很吃力，不是很懂，有很多的问题没有解决，最大的问题就是，有很多问题出现了都不知道怎么描述我的问题，这才是最大的问题。

github actions让自动化变得简单。github官网有一个菜单入口MarketPlace，没错里面就是一些常用的actions，具体怎么玩可以看github官方案例，也可以先看一下我的Github Actions 自动部署应用实现笔记。

docker让我的应用部署起飞。我的应用已经全部docker化了，可以先看一下我的实现Docker镜像的制作与使用。

NeteaseCloudMusicApi支持了音乐播放列表的后台动态控制。我的播放列表终于不再裸奔了。

mongodb嗯~~暂时没什么，好像有一些新的比较好玩的工具，没时间去试。

nginx-js可以用js的语法去配置nginx了，这个不错，我想去尝试一下，刚好马上证书到期了，这个很期待。

webComponent仔细看了一下github的网站结构，我发现好像github早就开始使用webcomponent了。试玩了一下，感觉还是很不错的，要是可以把组件的事件代理解决一下就好啦，如同react一般地去使用component元素。

preact相当舒服的react mini版本，基本适配了react的全部api，使用起来还是不错的。

webpack5 和 vite今年的明星项目莫过于vite了，试了一下vite+v3感觉相当棒，顺便把之前搭过的微前端的基座应用换成了vite。

B站的神奇之旅

在去年我看过了一系列的纪录片，相比现在的一些电视剧，纪录片都比他们有意思。

卸载抖音我丝毫没有犹豫，那没什么大不了，但是b站让我很难做呀。

我几乎每天都混迹在B站，今年的我很幸运见证了最快百万王冰冰，可鸽可泣小约翰。美食主播盗月社带给我的是快乐，嘉佑生宣让我重新认识了那些课本上的熟人，想不到短短的一句“庆历四年春”的背后居然还有这么多的波折。

我喜欢《深夜食堂》，也说不出究竟喜欢哪里，或者是喜欢哪一些人，可能只是喜欢日剧夏日午后般的平淡。尤其推荐《凡人修仙传》，看的很爽，真的很不错。

《肖申克的救赎》是我每年必看的电影，他提醒着我无论在什么环境里面生活多久也不要放弃自己，永远保持希望，不要被环境同化。

《怦然心动》令人触动，我到哪里去找我的初恋，你大爷的，为什么我现在才看这部电影~~

《戚继光》短短的六集所展现的内容比起那些三十几集连续剧强太多了，我觉得电视剧可以退出历史舞台了，把钱拿来做方块人都比他强。

《湮灭》根据《遗落的南境》改编，说实话很受震撼，但是电影最后所表达的究竟是什么意思，顶塔消失了，他们已经是新人类了，始终牢记是反射而非复制。

更离谱的是，可以看到各大高校的课程分享，我已经在b站看过了好几个up主赏析《红楼梦》，而且讲起来条条是道，很感慨啊，我还是书读少了。因为我看到的和别人看到的差别居然这么大。

除此之外，我还在b站里面找到了一些专业相关的课程，有关于nodejs、mongodb、flutter和docker。学习的平台已经搭建好了，接下来就是看自己寻找靠谱的视频资料了。

直播行业将会是这个娱乐时代中最普遍的职业，门槛最低的职业。只需要一台手机就可以开启直播了，我试着玩了一下B站的直播，操作很简单。当然有时间会看一下游戏直播，我最近很喜欢iwanna这个游戏，注意可不是喜欢玩，是喜欢看别人玩。

我在云村待了2000多个小时

如何开启自我保护机制？如果没有答案，那就戴上耳机。

每天早上醒来，已经形成了一种习惯，首先打开网抑云，随机播放。出门时戴上耳机，隔绝了整个世界。如果可以打字交流，绝不会说话。

我沉迷在《金风玉露》当中无法自拔，它真的很好听~~

笛声悠长，散播这无尽的缠绵哀怨。我看到歌名就联想到了“金风玉露一相逢，便胜却人间无数”，不知道他在期待着什么，只知道留下的是如汉水般连绵不绝的遗憾。

来，拿出笛子，先来一个欢快的，让大家折磨一下。

反思

遇到问题不暴露，暴露之后不解决，解决之后不总结，总结之后不记录，等于这个问题我从未经历，从未解决。

各位客官，别太相信自己的大脑，它的存储保质期真不太长~~

现在真实地发生在自己的身上，是因为年纪的关系还是其他的问题，很多东西长时间不去接触，再次谈论的时候我发现，我的记忆是一片空白。很多问题分明之前已经解决过，但是一些重复问题还是需要去google一下。

所以现在遇到问题了，我会提前把问题截图记下来，相关的google链接也会记下来，提供一些简洁的描述，增强自己的记忆力。它就是我的问题检索索引，最重要的是，不要简单的复制粘贴，手敲一下增强记忆。

不求甚解的理念不适合专业性较强的问题。业务相关、专业相关的文章应该持有的态度应该是庖丁解牛，而不是不求甚解。我现在一直在看之前群里发的一些面试题，并不是为了准备面试，而是面试题里面体现出了很多我不会，不了解的东西。我认为专精是专业性文章的指导方针。

记录和归类貌似也是一个学科，每一个人都需要自己去寻找适合自己的方式，以达到构建一种高效的储存和读取模型。我曾经在b站上面看到了一个分类的视频，看到之后很受教育，但是我现在仍然在摸索的过程中。

分析问题，一般我是围绕几个点：“是什么？为什么？怎么做？”。首先分析一下他是什么类型的问题，我之前是不是也遇到过类似的问题，那样就可以快速检索得出结果。既然是与之前遇到的问题相似，那它为什么表现出了一个独有的特性，那是不是也有其他的问题延伸出来。最后已经列出了全部的线索，结合一下前期的遇到的问题和解答步骤，尝试做出针对当前问题的解答。

从分析问题到得出结果，它是一个过程。能不能分析出什么问题是前期准备，能不能解决问题是最终结果。也许很多情景下，我的能力不足以解决我分析出来的结果，但是我相信一定有解决这些问题的高人存在。所以，有没有解决问题的能力，并不影响我尝试分析问题。

阶段性结束了

又一年结束了。

我还是一如往常，没有长进，没有改变，孤身一人。

乾上坤下，又一年开始了。

什么是github actions? 我们可以使用github actions做一些什么事情?怎么实现我们的需求?

我们在日常的开发过程中，部署过程中或者是更新日志的发布，一定会重复地执行一些操作。我一直在寻找和尝试一些简单、自动化的操作，免去一些重复操作。

首先说明，我也是头一次运用github actions，不过是在完成了一些操作之后，反过头来记录一些我是怎么做的。

什么是Github Actions

先从一个简单的配置文件，来认识一下github actions。.github/workflows/first.yml

name: Github Actions Demo First

on: [push]

jobs:
  logger: 
    runs-on: ubuntu-latest
    steps:
      - name: 'runner task1'
        run: echo 'actions runner task1'
      - run: echo 'actions runner task2'
      - run: echo 'actions runner task3'

首先文件的类型是yaml,文件名的后缀是yml，所以我们需要提前学习一下yml的语法。其语法和json的语法很相似，上面的yml文件翻译为json，其实就是这个样子:

{
  "name": "Github Actinon Demo First",
  "on": ["push"],
  "jobs": {
    "logger": {
      "runs-on": "ubuntu-latest",
      "steps": [
        {
          "name": "runner task1",
          "run": "echo 'actions runner task1'"
        },
        {
          "run": "echo 'actions runner task1'"
        },
				{
          "run": "echo 'actions runner task1'"
        }        
      ]
    }
  }
}

只要是在语句之前加上-号，那么它的父级会自动解析为数组，在:之后的换行符会解析为对象。其语法对比json来讲，更加简单。

不出意外，其执行成功的结果就是这个样子:

文件的结构分析

在github官方对github actions的文档描述看，上面的例子虽然简单，但是已经包含了事件流的基础元素。

• Workflows
• Events
• Jobs
• Actions
• Runners

现在对比这么一看，跟我之前写过的docker-compose的文件结构相当相似。要知道上面的元素全部是复数，就是说可以有一个也可以有多个，只要保证了基本的结构不错误，那你可以随意的加多个任务。

需要注意的是，对于Jobs下的子任务，都需要指定runs-on属性，要不然会抛出：

ERRO[0000] 'runs-on' key not defined in Github Actions Demo First/tags 

Workflows文件一般是放在.github/workflows文件夹内部，我看了好几个开源项目的文件目录大致上都是这样，因为github会自动拉取这个文件目录下以.yml结尾的文件作为任务文件。

Events是一个关键点。下面我贴上两个地址，是github actions的官网上对于Events模块的描述。events-that-trigger-workflows,workflow-syntax-for-github-actions。on可以监听到的事件官网上提供了一个索引表，和它们相关的写法和用法。同时不单单是对事件，还可以针对单独的分支进行事件监听。

name: Github Actions Demo Second

on: 
  push: 
    branches: 
      - main
  pull_request:
    branches:
      - main
  schedule:
    - cron: '/5 * * *'
    
  jobs:
  	reb:
    	runs-on: ubuntu-latest
      steps: 
        - name: 'push main'
          run: echo 'push events'

Events.schedule定时任务。在文档上schedule出现的位相当靠前，估计这个是一个相当不错的特性。它的函数是一些云函数，官网给出了一些例子，但是我目前还没有测试，所以先放着，以后再玩。

Jobs和它的一系列参数列表和语法。Jobs是Github Actions最核心的元素了吧，我们需要的各种各样的功能能不能实现，怎么实现就依赖于怎么实现。其中，我们比较关注就是一些环境变量问题。env提供了这一功能，另外use和with成对使用。

其中，介绍Jobs任务的另一种使用，串联。任务可以是单行，也可以是多个任务有先后、互相依赖的关系存在。所以在github actions中提供了jobs.jobs_id.needs 这个配置项，让我们可以个性化配置。使用方法也简单

jobs: 
	reb: 
		runs-on: ubuntu-latest
		needs:
			- first_task
			_ second_task
		steps:
			- name: 'thrid_task'
			- run: echo 'thrid_task'

jobs.jobs_id.runs-on表示在哪一个虚拟机执行任务。 现在提供的虚拟机，可能我们日常使用ubuntu就够了。它有以下几个选项，可能以后还会再增加。

Docker 的自动编译和推送

这是一个github 官方提供的例子，actions来自于docker官方仓库。

可以查看我的编译yml，也可以直接查看github官方例子。对比一下，你就会发现没有什么太大的差异，只是我换成了分支名，而github例子使用的hashid。

因为需要上传Docker Image镜像到Docker Hub，可以使用由docker官方提供的几个actions：

1. docker/login-action 登录用，只有登录状态下才可以推送镜像
2. docker/metadata-actions 配置image的版本号
3. docker/build-push-action 编译和推送

Release 版本更新

不得不承认，有很多的工作或者是操作都可以用一些工具自动生成。比如，我现在项目的更新日志，仍然还是在本地执行脚本，生成日志之后再推送到github。

每一次更新，发布release版本时，还需要把本次更新的内容复制粘贴到版本说明中。看起来可以改变一下，让这一步工作自动化进行。

版本更新CI/CD的一个重要环节，其价值不可谓不巨大，可以极其方便地控制一些手动操作。尽管现在有一个工具可以了本地测试，但是还是有缺陷，在我做完了全部的流程之后，我回过头来仔细分析了一下。我之所以干的这么不顺利，就是因为我不太了解linux和虚拟机相关的知识。

另外不太熟悉github actions相关的进阶的玩法。由此可见，我这种英语不行，我看着文档上面例子，也可以做出一些我想要的功能。另外也归功于github actions的仓库，里面准备了一大批日常使用的功能，完全解决了我的需求。

现在介绍使用的actions:

+ **actions/checkout@v2** 应该算是使用频率最高的actions了吧，只要是涉及到了git相关的操作就离不开它
+ actions/setup-node@v1 选择任务执行的nodejs版本，可以控制其版本号
+ **release-drafter/release-drafter@v5** 生成release notes的一个actions，可以生成这个版本号的提交日志
+ **appleboy/ssh-action@master** 服务器登录执行指令

注意:

1. 在使用release-drafter的过程中，必须使用pull_request 这样才可以拿到每一次分支的更新日志
1. appleboy/ssh-action 需要注意的是有多种连接服务器的方式，如果使用的用户名+密码，需要查看远程服务器的是否支持连接
1. 如果条件允许，还是拆分多个任务比较好，不要都写在一个任务里面

我之前用的是google浏览器的的一个插件，大多数朋友可能都有用过，就是GHelper。

但是在公司内部，不知道出于什么原因，也可能是内网的原因，这个插件失效了。所以只能另寻他法，终于找到了一个几乎不用啥配置的工具，但是也需要交一点点保护费。

Mac上使用

在Mac上使用特别的简单，因为我本身的意愿就是找一个零配置的工具。

而且，Clashx在Mac上的表现也相当的亮眼，颜值还是不错的。

在交保护费的平台拿到clash的订阅地址，点开菜单栏的猫头，找到配置->托管配置->管理。把你的clash订阅地址贴到管理里面，之后更新列表，不出意外的话，在成功更新之后就可以看到代理服务器列表了。

我选择的代理模式是规则模式，打开系统代理之后。打开浏览器输入google看一下，不出意外现在是可以访问外网了。

这是不同于win10平台的一点，在window平台上，用浏览器的无痕模式可以直接访问外网，但是普通模式不可以，还需要用switchomage这个插件做转发。真是有够麻烦的。

最后，附上clashx在Mac平台的下载地址clashX，版本号是1.72.0。在Mac上使用极其简单的，几乎没有费什么工夫就成功的跑了起来，完全没有遇到什么麻烦。

window10 的 Clash

在window平台的上的客户端不再是ClashX，而是Clash。都是一家人没什么太大的区别，都是基于go。不得不说，在各个平台使用Clash都很简单，几乎没遇到什么大的麻烦，但是在window上需要多处理一点。

在这里附上Clash的下载地址clash_for_window(https://github.com/Fndroid/clash\_for\_windows\_pkg/releases)。该链接来自于**github**，请放心使用。

首先，如果没有买飞机票，请先交保护费买一张飞机票，获得clash的订阅地址。另外还需要给google浏览器装一个插件Proxy switchyOmega。

Android 的 Clash

第一贴上clash_for_android的下载地址：https://github.com/Kr328/ClashForAndroid/releases，该链接来自于**github**，请放心使用。

在进入app之后，引入眼帘还是熟悉的一个黑色的猫头。接下来的操作还是老一套，点开配置进入配置页之后，点击右上角**+**图标，会进入“创建配置”页。进入”创建配置”页之后，选择从URL导出，这里就是贴上clash的订阅地址。

完成这些操作之后，回到首页。看一下第一栏的文案，如果是“运行中”就表示已经正常代理了，打开手机浏览器，进入google浏览器，或者是打开twitter。如果是“已停止”就点击启动，不出什么以外，就可以正常使用了。

手机上的操作就这么简单。

只要是找的源足够靠谱，那代理的网速应该差不了多少，足够日常的使用。

注意：

1. clashx教程 — MacOS
2. 飞机场-优云666
3.  飞机场-飞世云 

在10.1的假期中，我用TS重写了博客的前端应用，同时用sass改写了全部组件的样式。对于组件的设计，全部借鉴于ant design的设计规范和开发规范。

第一版的Next应用写的不是很满意，很多代码和实现都不是我喜欢的那一种。恰逢10.1假期，改写了大部分的组件的代码。

由于近期的工作比较多，平时又很累一直没顾得上写一写，这一次重写遇到的问题和解决的方法，以及对整个应用工程化的实现的记录。现在已经过去了两个多月了，很多细节已经回想不起来了。没办法，只能看着现在的代码总结一下。

提交规范

无论我们做任何项目，从规范代码提交的开始，应该是对整个项目最负责的体现。

不知道从什么时候开始，我个人的提交规范就朝着angular的方向了。我记得当时我看了一篇讲述angular提交规范的博客，当时一看顿时觉得仪式感太强了，整个commit记录一眼看过去相当整齐，从那时起，我觉得angular规范是最好的。

代码规范和样式美化选用 prettier 和 eslint 。代码的样式美化和统一，给我的感觉就是舒服。这里没什么可以说的，网上的教程一大把，但是我偷懒了，对于react的规则，我用是的umijs的规则，当然nextjs自身的规则继续保留。

只要是严格的遵循了angular的提交规范，就可以使用 conventional-changelog 工具，快速的生成本次发布的版本的更新日志，这里附上近期的更新日志。大致就是以下这个样子，看起来就是满满的仪式感。

Github Actions用起来的感觉就是一个字，太爽了！之前一直不会用，一直在研究到底是怎么玩的。直到看阮老师的博客，发现了一个新的工具act，可以在本地调试github actions。可以监听git的merge事件，来做一些自动化操作。

所以现在，我把主分支切成了main分支，每一次的功能迭代改为pull merge操作。因为我看到了next的官网上有推荐，可以使用Vercel持续集成应用，这样每一次的merge操作就可以自动发布到Vercel容器了。

组件的设计规范

基本原则还是遵照我之前的总结《浅尝一下UI设计》，基本的设计不变，但是改成sass函数之后，整个css部分变得更加地整齐、清晰和简单。

这里不得不提到sass中的函数和混入，在sass的官网中有它们相当具体地实现。这次我用到的基本都是Map类型操作。我举一个相当简单的用例，实现组件的大中小三种类型的样式函数。文件名: vars.scss

	$font-size-base: 14px;
	$compose-base: 8px;
	$sizes: ((small, $font-size-base - 2px, $compose-base * 0.5),
	  (middle, $font-size-base, $compose-base),
	  (large, $font-size-base+2px, $compose-base*2));
	
	@mixin getSizes () {
	
	  @each $size,
	  $fontsize,
	  $padding in $sizes {
	    .is-#{$size} {
	      font-size: $fontsize;
	      padding: $padding;
	    }
	  }
	}

在调用getSizes函数之后，自动生成了.is-small、.is-middle和.is-large三个类名，对应着组件的三种大小状态。在此处我只定义了基本字体大小和内边距两种属性，如果需要扩展属性，可以很轻易地实现。

其编译之后的代码如下:

所以，我们可以借助类似的一些自定义函数，在快速完成我们样式代码的同时减少代码量。less和sass其功能相差不大，基本功能都可以实现，具体的一些功能函数可以参考ant的代码实现。

React.FC 全函数式组件的实现

完全舍弃类组件，全部由函数式组件构建。

如果你不会做，不妨跟着会做的人做。

在本次更新中，很多组件都是模仿ant。包括对于TS的使用下的React组件定义，自定义组件对外暴露的属性，组件内部classname的命名和条件渲染，大量代码都借鉴了ant。

Hooks的实现借鉴了另一个开源库ahooks，但是hooks文件的规则还是沿用umijs。

当然，audio的单例模式实现也发生了一些变化。在init阶段的单例实现没有任何变化，但是我创建了一个全局的context，在这个context中新建了ref来保存audio实例。整个应用似乎不太需要Redux。

主题切换，不再使用原方案，改为使用脚本实现。同时，bubble泡泡也改为使用脚本实现。你可以直接下载bubble.js(https://src.wuh.site/scripts/bubble.js)脚本体验。

Accessibility 可访问性指标

在google浏览器的性能测试工具中，就有_Accessibility_指标。在ant的实现中，我们可以发现role 和 aria-* 属性。当时我看到的时候很迷惑，因为我从来没见到过html元素的属性中，有role这个属性。知道后来我听了_《重学前端》_这门课，我才知道原来是这么回事。

除此之外，还有键盘的可访问性，那就是tabindex。其对应的键盘按件就是tab键。在对一个html元素配置该属性之后，就可以通过tab键聚焦。如下:

  <div tabindex='0'>hello</div>

我们都知道在Html5 中发布了一些新的元素，这一些元素被称之为语义化标签，我记得在当时，我是完全用section标签取代了div标签。现在我的大部分标签改回了div。

所以，在一轮的重构中，我对大量的元素加入了role属性，覆盖率大致上达到了80%。只要是涉及到了可交互的组件基本上完成了配置。页面可点击按钮全部换成button元素和a元素。

或许，我们都应该听老师傅的话：如果你不知道的怎么用语义化标签，那就不要用

App的结构化优化，NextSEO和点击事件上报

一个网站的SEO是极其重要的，所以在一次的重构中，我选择了NextSEO库，不再使用自己维护的代码实现。这个仓库满足了我全部的需求，因为我只需要配置google结构化，标题，关键字这一些属性，其他的我并不需要。

Gtag可以完成满足我的上报需求。首先我对页面的按钮进行了基础分类，大致分为了: normal、loadmore、link、share、behivor。这样，我完成了页面点击按钮的事件上报。

接口上报还没来得及做，现在我的服务后台换成了Nest应用，很多功能都没有时间去做。

自动化构建，Docker的一键更新和发布

我优化了Dockerfile构建文件，改成了分段式构建。

早前我是自己的野路子，能把应用跑起来就行，但是后来我发现，构建的Docker镜像太大了，感觉告诉我有点点不太对劲儿。在我改了构建文件之后，现在我的镜像的体积是91M。

构建步骤大致分为三个阶段: 初始化、构建、运行时。

本次升级内容，如下：

1. 不再使用npm, 改为使用yarn
2. 改为使用ali的镜像源，减少依赖的安装时间
3. 安装jq一个json文件的解析工具
4. 改为分段式构建

# ==================== Deps ==============
# =================== 安装依赖 =============
FROM mhart/alpine-node as deps
LABEL maintainer = "shadow [wuh131420@gmail.com][6]"
  
WORKDIR /usr/src/app
  
COPY package.json yarn.lock /usr/src/app/
  
RUN apk add jq
RUN npm config set registry https://registry.npmmirror.com
RUN yarn
  
# ================== Builder ================
# ================= 编译 ===================
FROM mhart/alpine-node as builder
WORKDIR /usr/src/app
  
.......
  
# ============== Runing ===========
# ============== 运行时 ===========
FROM mhart/alpine-node AS runner
WORKDIR /usr/src/app
  
ENV NODE\_ENV production
...
  
USER nextjs
  
EXPOSE 3000
  
CMD ["yarn", "start"]

更为关键的是自动构建，自动升级和镜像清理脚本，结合一下github actions，一切都变得舒服了起来。

RSS 聚合内容的实现

只要有优质的订阅源，我们完全可以只使用RSS阅读器，就可以享受阅读的乐趣。它是一个信息板，只关注我想关注的内容。所以现在的一些博客网站都会配置rss。

怎么配置实现rss就成了我们需要关注的内容啦。

在这里我推荐使用Feed(https://www.npmjs.com/package/feed)，但是我的实现稍有不同。

每一次更新博客之后，都需要更新维护的rss.xml文件，只有这个文件更新了，订阅器才会有更新推送。现在我把这个功能集成到了我的管理后台，我的feed文件托管在aliOSS，这个是我的feed(https://src.wuh.site/common/rss.xml)。

web worker 来一个自动切换主题的实现

我用 web worker 注册一个时间轮询器，用于获取当前设备的时间。白天使用light模式，晚上变为dark模式。怎么让它们实现自动切换就是一个比较指的研究的问题啦。

难道要在主线程中加一个定时器，让它每次30分钟更新一次吗？

或许，有别的方式。在不占用主线程的资源的前提下，还可以监听时间的变化，在满足条件的前提下，切换网站的主题模式。

这是一个相当简单的实现，如果你感兴趣，可以在项目的源文件里面，查看相关的代码。

图片格式转化为webp

.webp类型的文件，从文件可压缩的大小的比率上看具有相当的优势。但是目前为止，我只是把网站的背景图片和部分封面图改为了.wepb，大部分文件仍然还是.png。

来自于h5的新标签picture，提供了非常棒的降级方案，只需要配置额外的基础源就可以放心使用webp文件。

看起来，需要实现一下转换图片的格式了

免密登录，用到的就是一个公钥。如果之前在机器上用过github的ssh模式，那你一定还记得，秘钥生成到哪一个文件夹下了。

用到的指令就一个 ssh-keygen,几乎可以不用加任何参数，直接生成一对key文件: id_rsa.pub和id_rsa

ssh-keygen --help

 usage: ssh-keygen [-q] [-b bits] [-C comment] [-f output_keyfile] [-m format]
                  [-N new_passphrase] [-t dsa | ecdsa | ed25519 | rsa]
       ssh-keygen -p [-f keyfile] [-m format] [-N new_passphrase]
                   [-P old_passphrase]
       ssh-keygen -i [-f input_keyfile] [-m key_format]
       ssh-keygen -e [-f input_keyfile] [-m key_format]
       ssh-keygen -y [-f input_keyfile]
       ssh-keygen -c [-C comment] [-f keyfile] [-P passphrase]
       ssh-keygen -l [-v] [-E fingerprint_hash] [-f input_keyfile]
       ssh-keygen -B [-f input_keyfile]
       ssh-keygen -D pkcs11
       ssh-keygen -F hostname [-lv] [-f known_hosts_file]
       ssh-keygen -H [-f known_hosts_file]
       ssh-keygen -R hostname [-f known_hosts_file]
       ssh-keygen -r hostname [-g] [-f input_keyfile]
       ssh-keygen -G output_file [-v] [-b bits] [-M memory] [-S start_point]
       ssh-keygen -f input_file -T output_file [-v] [-a rounds] [-J num_lines]
                  [-j start_line] [-K checkpt] [-W generator]
       ssh-keygen -I certificate_identity -s ca_key [-hU] [-D pkcs11_provider]
                  [-n principals] [-O option] [-V validity_interval]
                  [-z serial_number] file ...
       ssh-keygen -L [-f input_keyfile]
       ssh-keygen -A [-f prefix_path]
       ssh-keygen -k -f krl_file [-u] [-s ca_public] [-z version_number]
                  file ...
       ssh-keygen -Q -f krl_file file ...
       ssh-keygen -Y check-novalidate -n namespace -s signature_file
       ssh-keygen -Y sign -f key_file -n namespace file ...
       ssh-keygen -Y verify -f allowed_signers_file -I signer_identity
       		-n namespace -s signature_file [-r revocation_file]

在本地生成的key文件，推送到服务器上，在此之前先看下服务器的ssh服务开启了没有，没有开启的打开就好。

systemctl status sshd

systemctl start sshd

在服务器上，设置一下.ssh和authorized_keys的权限，网上有部分资料将权限设置之后，免密登录才生效。

sudo chmod 700 ~/.ssh
sudo chmod 600 ~/.ssh/authrized_keys

设置之后，测试一下，看看免密登录能不能成功：

ssh root@101.101.101.101

只要可以正常进入云服务器就说明已经生效了，如果还不行的，检查一下配置文件的路径或者是权限。

最后，在本地的.ssh目录，新增一个配置文件config:

Host aliyun
    user root 
    hostname 192.168.1.1 
    IdentityFile /Users/root/.ssh/id_rsa  (密钥的本地地址)

执行一下ssh aliyun，就可以登录云服务器了。

参考资料

• SSH 免密登陆配置

最近github的速度是在是太慢了，实在是受不了了，所以只好把镜像的编译工作放在了本地。在本地制作镜像然后托管到dockerhub，直接使用线上镜像了。

换一句话描述: 之前在服务器做镜像，现在在本地做镜像。

首先，介绍一下，这次更换部署方式用了哪一些工具和一些使用的坑，更多关于使用的方法和问题的排查。

1. docker
2. docker-compose
3. Bash
4. Npm/yarn & nodejs

基本的流水线节点大致如下:

1. 第一步: 本地制作镜像文件
2. 第二步: 推送镜像文件至远程dockerhub
3. 第三步：服务器更新镜像文件
4. 第四步：重启容器，重启nginx

连接服务器更新的脚本，没有提交到github，但是我会讲一下我是怎么做的。

docker

具体的安装流程可以百度一下，网上有很多的教程，就不具体说了。这里贴上一些我经常查看的一些网站，当然都是关于docker的。

1. docker-run(docker的官方文档，当前链接为docker的指令集文档)
2. docker从入门到实践(中文版的docker文档，文档很详细，基本满足我现在的需求)
3. docker.restart(镜像更新后，不断机更新重启容器)

简单列一下我用的比较多的一些docker的指令：

• docker build
• docker run
• docker pull
• docker push
• docker tag
• docker create
• docker login
• docker config
• docker restart

首先，我是将镜像文件托管到了docker的官方网站，所以login是必须要执行的一个指令。除此之外，每一个镜像文件必须指定两个版本号。docker pull指令默认拉取的是docker-image:latest版本号，同时我必须将这个镜像打上另一个版本号，以防需要镜像回退。

首先，在bin目录下创建一个脚本文件，执行环境指定为node，docker-push.sh

#!/usr/src/env node

所以，在push操作之前必须先只执行一句代码，docker-push.sh:

docker build -t 'shadowu/wuh.site:latest' -t 'shadowu/wuh.site:1.6.0'

另外一个版本号，来自于package.json文件中的version字段，基于这个文件可以更新一下执行的脚本:

version=$(node -e "(function () { 
  const path = require('path')
  const pathname = path.resolve(__dirname, './package.json')
  console.log(require(pathname).version) 
})()")

docker build -t 'shadowu/wuh.site:latest' -t 'shadowu/wuh.site:'$version

执行环境指定为node了，我才可以用nodejs的模块化拿到package.json文件里面的version，这个是我能想到的最简单的方法。

然后，在脚本指令里面，为这个脚本加上一个命令:

"scripts": {
  "build:docker": "./bin/docker-push.sh"
}

镜像的文件制作``Dockerfile`，可以访问我之前写过的一篇《从PM2到docker, 离不开的Nginx》,不用写太多，简单制作一下，先让项目可以用docker跑起来，其他的再说。

docker-compose

在很早之前，docker-compose还是需要单独安装，但在更新了docker的版本后，docker-cli里面集成了docker-compose，相当的方便，我在项目的描述文件里面记录了两种启动容器的方式。一种是用docker-compose 启动本地制作镜像，另一种是docker启动线上镜像。

在项目里面我提供了docker-compose.yml的执行文件，在不考虑其他优化的前提下，用docker-compose启动镜像是如此的简单。

version: "3"

services: 
  nextjs_app:
    build: ./
    ports: 
      - 3100:3000

必须的配置项就这么简单，但是优化镜像体积的时候，我们还需要用到volume挂载卷，和一个针对node_modules的专用镜像。两个镜像之间的网络桥接用到的network。

目前我遇到的，比较麻烦的处理就是这两个，因为也是头一次做，很多东西都需要慢慢摸索。

在之前版本中，服务器端的执行脚本是这个样子:

   frontend:
    build: frontend
    ports:
      - 3100:3000
    stdin_open: true
    container_name: frontend
    restart: always
    depends_on:
      - backend
    networks:
     - react-express
     - mongo-db

现在不用执行编译过程，简单改一下，直接使用镜像名+版本号就好:

   frontend:
    image: shadowu/wuh.site:latest
    ports:
      - 3100:3000
    stdin_open: true
    container_name: frontend
    restart: always
    depends_on:
      - backend
    networks:
     - react-express
     - mongo-db

你永远可以使用且可以只使用 docker-compose up -d 指令，来完成你想完成的任意操作。

Bash

首先，介绍一下有关bash相关的教程《Bash脚本教程》(来自于阮老师的教程，链接地址直接指向了Bash的启动环境篇)。

教程的内容很多，但是我用到的实际上也没几个，目前只会写一点相当基础的语句，但是没关系，可以慢慢来。

现在使用的一个source指令，用来加载同步服务器端的脚本文件。

ssh username@ip

$ password

这个是比较常用，使用ssh登录服务器的操作。输入密码是必不可少的一步。只有密码正确了才可以操作服务器，我已经将一些基础的操作全部做成了脚本，现在只差服务器的同步。那么有没有一种方法可以免去输密码的这一步？

我用到的一种就是安全证书。

能力有限，原理我说不清，感兴趣的自己百度。

执行结果与相关问题

执行脚本之后，能够正常的走到这一步说明没有遇到问题，而且已经推送成功了。

初次制作的时间还是比较长的达到了43s，别慌，之后的编译过程会快一点。有些问题需要注意下：

1. 看一下执行过程，停留在yarn install 的过程特别耗时，有一次达到了200s+，只好改成淘宝的镜像源了。

2. volume的配置项，不管我放到哪里都感觉没用，也不知道是不是使用的姿势不对。但是我看到了一种方法就是将node_modules单独做成一个镜像，容器之间是可以互相访问，免去每一次制作镜像都需要安装依赖，后面实践一下。

3. 启动容器一定要加上端口号，容器默认端口是3000，但是浏览器访问3000端口是没办法正常访问的，这里我测试过，加上一个映射端口就没问题。

4. docker-hub设置为公共源，才可以用到一些三方工具，比如生成一个icon标签放在github上面。

   

5. 注意nodejs的版本，有很多莫名的问题是nodejs的版本带来的问题，linux上可以使用的n这个工具，可以快速的切换nodejs的版本

6. WORKDIR是指app在容器里面运行的文件目录，在遇到镜像可以正常制作，但是容器死活起不来的时候，可以减掉一些镜像文件的配置项，进入到容器里面去看一下究竟遇到了什么问题

docker的常用指令

docker container ls -a docker image ls -a docker stop container_id & rm contaier_id``docker image rm image_id

以上是使用的频率最多的一些指令，同时我们还会用到 docker container inspect和docker image inspect，它们是用来查询容器和镜像的基础配置的。

• 必须删除容器才可以删除创建容器的镜像，而再此之前，必须先停掉容器，才可以删除容器。
• docker run和docker create 在创建容器的时候，其实没啥大区别，需要注意的是，最好加上-it配置，在容器正常启动后会返回容器id
• 就用docker-compose，有了它一切变得简单起来

工具

Docker Desktop

官方提供的一个工具，使用简单。

1. 可以相当直观的看到现在使用的机器上面镜像和运行的容器

2. 可以看到目前容器占用的资源

   

3. 可以看到一些变量属性

4. 可以快速布置k8s任务

======= 分割线以下是更新内容 =======

javascript中的继承

这两天没事，在翻看红宝书的继承篇，重新学习了一下下js中的继承。出于对Es6中class 类继承的好奇，我在babel里面试了一下，才发现Es6中class类继承，实际是寄生组合式继承，也是一下我要介绍的一种， 如图：

在红宝书中主要介绍了一下5中实现继承的方案：

1. 原型链继承
2. 构造函数继承
3. 组合式继承
4. 原型继承
5. 寄生继承
6. 寄生组合式继承

以下，我只记录它们主要的设计代码和基本原理，其实例可以访问我的codesandbox，里面有继承篇详细的例子。

原型链继承

基本思想就是利用原型，让一个引用类型可以继承使用另一个引用类型的属性和方法。详情查看例子原型链继承。

每一个构造函数都有一个原型对象，而原型对象中又有一个指针指向构造函数，实例也有一个指向原型对象的指针。如果让原型对象等于另一个类型的实例，那该原型对象就具有了另一个类型的构造函数。如果另一个类型的原型中又有另一个类型的实例，层层递进就有形成了一种实例与原型的链条，这个就是原型链。

对SubType的原型对象改写为SuperType的实例，此时可以将SuperType称之为SubType的超类，那SubType即为子类。

如果继续将SubType作为超类，对SubType2改写原型对象，那SubType2将同时具有SuperType和SubType的属性和方法，尽管SupType2不是SuperType的子类。这个就是继承链最简单的一个实现例子，

function SuperType () {
  this.name = 'super'
}
SuperType.prototype.getName = function () { return this.name }

function SubType () {
  this.name = 'sub'
}

Sub.prototype = new SuperType()
Sub.prototype.getSubName = function () { return this.name }

function SubType2 () {}
SubType2.prototype = new SubType()

注意：

1. 需要注意的是，重写子类原型的语句必须出现在声明Sub原型方法之前，原因很简单，因为原型链继承是重写子类原型对象。重写语句后自定义子类的属性和方法会被删除。
2. 在使用原型链继承时，如果超类中声明了复杂类型，后代子类会共享复杂类型的值。比如：子类1 更新了一个数组的元素的值，本次更新会反应到子类2。这个也是原型链继承的一个最大的缺点。
3. 不能使用对象字面量去创建原型方法，因为使用字面量后实质上是重写了原型链，切断与原来的原型链之间的联系。
4. 没有办法在不影响全部实例的前提下，给超类的构造函数传递参数。

借用构造函数

在子类的构造函数中调用超类的构造函数，即为借用构造函数的基本原理。详情查看例子借用构造函数

借用构造函数方法的出现就是为了解决原型链继承的复杂类型值会被各个实例共享的问题。

在子类的构造函数中调用超类的构造函数，其实质是将超类绑定在this中的属性复制到子类中，只有在调用子类的构造函数时，才执行超类的构造函数，所以现在的参数问题得以解决，各个实例间不会互相影响。

function Super (name) {
	this.name = 'super' || name
}
function Sub (name) {
	Super.call(this, name)

	this.name = 'sub'	
}

注意：

1. 相对于原型链继承，借用构造函数可以单独给实例传递参数了。因为属性是绑定在this上面的，只有在创建实例的时候才赋值，所以实例之间互不影响。
2. 但是，在解决了复杂类型值的问题之后，借用构造函数又有一个新的问题。属性和方法全部绑定在this上面，所以只能在构造函数内部继续声明其他的属性和方法，扩展性降低。
3. 同时，在超类的原型中定义的属性，对于子类而言不可见。所以必须在超类的构造函数中声明属性。

组合继承

利用原型链实现方法的基础和利用构造函数实现属性的继承，就是组合继承的基本原理。结合了原型链和借用构造函数的技术，同时具有了它们的优点。详情查看例子组合继承

在重写了子类的原型后，Sup.prototype实质上指向了Super.prototype，在Sup.prototype.constructor指向的是Super，这里需要手动将Sub.prototype.constructor指向Sub。

function Super (name) {
	this.name = 'super' || name
}
Super.prototype.getName = function () {
	return this.name
}

function Sub () {
	Super.call(this)
	
	this.age = 20
}

Sub.prototype = new Super()
Sub.prototype.constructor = Sub

注意：

1. 组合继承唯一一点就是需要两次调用超类的构造函数。

原型式继承

没有严格意义的构造函数，原型可以基于一个对象生成另外一个新对象，还不必为它声明额外的类型，就是原型式继承的基本原理。详情查看例子原型式继承

原型继承的实现特别简单，公式一样的三句代码。object函数实际是创建基于传入的对象o，生成的副本。每一个由object函数生成的副本，其状态都被共享了。

但是对实例进行扩展的方法是不会被共享的。

function object (o) {
  function F () {}
  F.prototype = o
  return new F()
}

注意：

1. 其复杂类型值的问题，如同原型链继承一样，会被每一个实例共享
2. 在es5中，已经新增Object.create方法，其效果与object方法一致

寄生式继承

寄生式继承，是与原型式继承密不可分的。其基本思想就是，仅创建一个封装继承过程的函数，在函数内部对新对象进行增强，然后返回增强的新对象。详情查看例子寄生式继承

就这样在由寄生式继承的函数返回的新对象，就有了源对象origin的属性和增强的属性。

所以，寄生式继承和原型式继承，主要针对的是对象间的继承，而非自定义构造函数。

function inherit (o) {
  var prototype = object(o)
  prototype.getName = function () {
    return this.name
  }
  
  return prototype
}

注意：

1. 其缺点与借用构造函数相似，其封装过程全部在函数内部，没有办法进行扩展。

寄生组合式继承

寄生组合式继承，指的是通过构造函数来继承属性，通过原型链的混成形式来继承方法。其基本原理就是： 不必为了子类的原型而调用超类的构造函数，我们需要的就是超类原型的一个副本。详情查看例子寄生组合式继承

可以使用寄生式继承来继承超类的原型，再将结果指定给子类的原型。

寄生组合继承，可以减去一步在子类外部调用的超类构造函数，避免将一些额外的属性附加到子类的原型链中，而且原型链还能保持不变。

所以，开发人员一致认为寄生组合式继承是引用类型最理想的继承范式。

function Super () {
	this.name = 'super'
}
Super.ptototype.getName = function () {  return this.name }

function Sub () {
	this.subname = 'sub'
}

function inherit (subType, SuperType) {
	const prototype = object(SuperType)
	prototype.constructor = subType
	subType.prototype = prototype
	
	return prototype
}

inherit(Sub, Super)

可以回到顶部，查看babel对class类继承实现的转换，仔细一对比，发现其实没有什么大的不同，从实现思想上来说是一致的。

Class 与 extends

ES6终于实现了基于类继承的方案了。可以使用extends关键字实现继承, 但是在子类中必须使用super关键字，因为子类没有自己的this。

class Parent {}

class Child extends Parent {
  constructor (props) {
    super(props)
  }
}

在ES5中，先创建的是子类的this，然后将父类的属性和方法添加到子类的this当中。 在ES6中，先将父类的实例添加到this中，然后用子类的构造函数去修改this。

注意：

1. 在大多数浏览器的Es5的实现中，都存在一个__proto__属性，该属性总是指向对应构造函数的prototype属性。Class作为构造函数的语法糖，同时具有__proto__与prototype两条继承链。
2. 子类的__proto__属性，表示构造函数的继承，总是指向父类。 Child.__proto__ === Parent
3. 子类prototype中的__proto__，表示方法的继承，总是指向父类的prototype。 Child.prototype.__proto__ === Parent.prototype
4. 在类继承中，__proto__属性是层层嵌套的，子类的__proto__属性的__proto__属性指向的就是父类的__proto__。 Child.__proto__.__proto__ === Parent.__proto__

总结

1. 在js中主要通过原型链实现继承。原型链的继承就是通过将一个类型的实例赋值给另一个构造函数的原型。这样，子类就可以访问超类中的属性和方法，与基于类继承相似。
2. 原型链继承的问题是所有对象实例共享所有继承的属性和方法，因此不适于单独使用，而解决的方法就是借用构造函数。
3. 借用构造函数，是通过在子类的构造函数中调用超类的构造函数。这样就可以做到，每一个实例有自己的属性和方法，但是也限制了子类的扩展，因为只能在构造函数内部声明其他属性和方法。
4. 使用最多的继承模式是组合继承，集成了原型链继承和借用构造函数优势。通过原型链来扩展方法，通过借用构造函数来实现实例属性的继承，唯一缺点就是必须调用两次超类构造函数，造成效率缺失。
5. 原型式继承，是针对于对象的一种继承模式，如非必要声明构造函数，可以使用该模式，其实质就是对源对象进行浅复制。
6. 寄生式继承, 与原型式继承息息相关。基于源对象生成一个新对象，然后对这个新对象增强后返回。
7. 寄生组合继承，为了解决组合继承会两次调用超类构造函数而造成效率低下的问题，将寄生式继承和组合式继承结合。通过寄生式继承对超类原型对象浅复制，然后对子类原型的构造函数修正，最后改写子类的原型对象。

寄生组合继承是基于类型继承最有效的方式。

搬山计划

在过去的一年时间里，自己除了工作就是工作，现在是时候做出一点点改变了，去玩生活去。

每一个人的身上的优缺点都是他的“闪光点“，而这些”闪光点“无时无刻不在反映着他自身。他永远也无法将这些闪光点抹除，不管它是积极的还是消极的。虽然无法消除消极的闪光点，但是可以隐藏，这一个过程给它命名一个名字——"搬山计划"。

整个人体，我把它当做一座山。你的优点和缺点全部集中在山顶之中，所以它们最显眼。而山脚处，则是普通地不能普通的个人因素。

现在我加入一个思考，当你接触观察一个新朋友的时候，你首先是关注他的优点，还是缺点？或者说，彻底影响你对他的个人看法是什么因素？

所以，我说：”自身修炼改造，犹如搬山。你永远也不能彻底改变沉疴旧疾，只能将山顶最引人注目的土往下搬。“

对于我而言，普普通通，平平凡凡，无人关注才是一种最佳的生活状态。

写字，读书，玩一些从未接触过的事物。

每一晚，我给自己安排了200字的控笔。

每一天，我给自己安排了2小时的阅读。

每一周，我给自己安排去逛一逛周边。

每一月，我给自己安排去见一见我在深圳的朋友。

现在，我对无人机很感兴趣，我似乎应该去买一个无人机玩一玩。

博客的前端项目基础功能终于做的差不多了，现在就差设计一下UI了，奈何我不是专业的UI，只能从前端的角度和一些专业的设计文档，去实现一下。

布局基础值

在我们构建网站的布局时，前端会依据设计图，设计网页。在开始工作前，我们会确认一些基础值，比如：

1. 间距相关
2. 色彩相关
3. 动效相关
4. 交互相关
5. 布局相关

我对设计的初级了解主要来自于Antd Design的设计思想，它们的组件设计的真的很棒！现在先用原生css实现一次，以后再考虑改为less。如下:

:root {
  /** Base **/
  --padding-base: 8px;
  --margin-base: 8px;
  --font-size-base: 14px;
  --border-radius-base: 3px;
  --line-height-base: 22px;
  --transition-base: all .5s ease;
}

基础属性可以配置的有很多，我先定义一些比较常规的属性，然后根据这些基础属性，延伸出一些派生属性, 比如:

:root {
  /** Base **/
  --padding-base: 8px;
  --margin-base: 8px;
  --font-size-base: 14px;
  --border-radius-base: 3px;
  --line-height-base: 22px
  --transition-base: all .5s ease;
  
  /** Margin **/
  --margin-base-2: calc(2 * var(--margin-base));
  --margin-base-3: calc(3 * var(--margin-base));
  
  /** Border **/
  --border-radius-2: calc(2 * var(--border-radius-base));
  
  /** Line Height **/
  --line-height-default: calc(var(--font-size-base) + 10 - 2);
}

将这些派生属性的配置全部集中到一个样式文件当中，不要在组件中再次定义样式，以保证全局样式的整体一致性。

当然，派生属性的倍数设置，并不是简简单单的乘于整数倍这么简单，有一些相关的公式或者是规范，详情可以参考antd的设计文档。例如:

1. 字号: 对于字号与行高的定义就是：lineHeight = fontSize+10 - 2。在Antd中基础字号为14px，相对应的行高为 22px，字阶的选择在3-5中之间，保持克制原则。

2. 字重: 对于字重只建议使用3种，400、500和600。具体效果可以研究Antd的Typograph组件，赶紧按照标准实现一下自己的个人网站试一试。

3. 字体颜色：个人认为，色彩还是很考验一个设计师的，因为需要搭配，整体搭配的色彩需要和谐，所以对于色彩的把握才是整个体系的重中之重。对于不同的应用场景有不一样的实现，需要提前定义好网站的主，次，辅助和标题的色彩。
   

4. 暗黑模式: 给自己的网站准备一套暗黑模式是一个不错的功能，现在我们可以直接使用Antd的工具生成，站在巨人的肩膀上扩展，让我们的自定义开发快乐起来。

现在先试着将我们的基础属性定义出来。就用Antd官网的工具生成一系列的色彩值，在此之前我们需要定义一个主题色彩。除此之外，需要定义字体色彩、border色彩和shadow阴影。

最为关键的是，我们需要设计一下页面的布局结构。从我个人的项目来分，可以分为：

1. 顶级标题
2. 二级标题
3. 三级标题
4. 一级菜单
5. 二级菜单
6. 基础描述文案 -- Description
7. 基本文案 -- Pages
8. 背景色对比
9. Border外边框
10. Strong 增强类型文案
11. Small 渐弱类型文案
12. Shadow阴影
13. Hover类型色彩

从「克制」方向来看，我做出了调整:

1. 页面上不需要太多的Heading标签，最多三级H1,H3,H6；
2. 准备左侧菜单入口或者是顶部菜单入口，不需要太多的菜单，最多两级；
3. 针对文章详情样式的调整，不用大的样式调整，需要多加一些细节调整；
4. 页面内只准备三级字重，Strong等于600、Normal等于500以及Small等于400；
5. 手势的交互增强，对比色彩、BorderRadius...
6. 渐进动画，全部使用transition增强页面交互

确认基础设置值

1. Padding 和 Margin的基数定为 8px, 整数倍增加，为8的倍数；
2. BorderRadius的基数为 3px，增加不限制；
3. FontSize的基数为14px，增加不限制；
4. LineHeight的基数为22px，与FontSize成线性关系，LineHeight = Fontsize + 10 - 2；
5. 定义主题色，中性色和主题色的反色；
6. 定义背景色，可能需要好几组对应的背景色，以对应不同的使用场景；
7. 定义Border边框色彩，不需要太多，可以直接使用主题色或者是中性色；
8. 定义动画函数，常见的函数是ease，linear，可以自己定义贝塞尔曲线；
9. 定义辅助色，辅助色彩丰富一点点

定义Heading类型主题

首先给文案类配置主题，达到一种视觉上的层次感。可以通过主题色系的不同的色彩，然后在页面上使用。

在上图中，定义了8种类型，可以按照上面的顺序，将生成的色彩，一一对应。但是可能也会有特殊的位置需要额外定义。比如我们现在需要生成两套文字色，以对应light和dark模式下的展示。

/** Light **/
  --color-base: #ebecec;
  --color-base-10: #0d0d0d;
  --color-base-9: #333333;
  --color-base-8: #595959;
  --color-base-7: #808080;
  --color-base-6: #a6a6a6;
  --color-base-5: #b3b3b3;
  --color-base-4: #bfbfbf;
  --color-base-3: #cccccc;
  --color-base-2: #d9d9d9;
  --color-base-1: #e6e6e6;

/** Dark **/
  --color-base: #141313;
  --color-base-10: #fafafa;
  --color-base-9: #f8f8f8;
  --color-base-8: #f3f3f3;
  --color-base-7: #e8e7e7;
  --color-base-6: #dcdcdc;
  --color-base-5: #adacac;
  --color-base-4: #7e7d7d;
  --color-base-3: #5b5a5a;
  --color-base-2: #454545;
  --color-base-1: #2c2b2b;

一共生成10种色彩，用于对应上图的8种类型，可用的色彩还是比较多的，先定义一套最普通的样式出来。

--title-normal-color: var(--color-base-10);
--title-less-color: var(--color-base-9);

--text-primary-color: var(--color-base-8);
--text-less-color: var(--color-base-7);

--text-second-color: var(--color-base-6);

--disabled-color: var(--color-base-5);

--border-color: var(--color-base-4);

--divider-color: var(--color-base-3);

--background-color: var(--color-base-2);

--table-head-color: var(--color-base-1);

中性色搭配

偷个懒，直接用Antd的中性色，以color-7为基准，大于7的为Dark模式下的色彩，小于7的为Light模式下的色彩。

生成这些中性色有什么用呢？

我把它搭配使用在Card组件当中，中性色是以Gray色彩为基准生成的，灰色是百搭色彩，没有什么色彩能够比中性色更适合做背景色彩了。除非你需要自定义一些Alert或者的Message类型的样式，才会去给这些组件定义一些不同状态下的背景色彩。

辅助色搭配

在选择辅助色时，需要考虑到的是辅助色和背景色以及字色的搭配，需要好好准备一下色彩，最好是从选择的主题色出发，去选择相近的色系。

Transition 与 Animate交互

我们最少需要准备两套动画，即入场动画和出场动画。举一个例子，我们给一个标签做hover特效时，定义在hover类中的就是入场动画，比如使用ease-in，那么定义在当前标签类中的即为出场动画，比如使用ease-out，这个样子给用户的体验是不是有了一点点趣味呢。

如果需要将我们的页面细节做起来，我们可以给每一个属性都指定一个特有的出场和入场动画，那看起来就更美妙了，但是我觉得用两个动画就可以了。

间距设置

现在我们的基础都是基于8px，几何倍数的增加或者是减少，这样看起来的页面的间距值就全部统一起来啦，从结构上确实好看，具体去看Antd的组件。我是觉得好看的~

除了8n这一种写法，还可以使用em单位和rem单位，em相对于父级标签的字号，rem相对于根标签的字号，也是一种结构性的写法。但是使用场景上有差异，用em单位我们通过Fontsize属性轻松实现自适应的组件，比如在项目中的AudioContronl组件和Button组件组，就是通过Fontsize来控制Audio按钮组的样式。

富结构化缺省页

查询结果结构化是我在做google查询优化时接触到概念，我认为这个概念也可以用到我们的构建个人网站的查询结果中。

举个例子404页面，我个人认为：在类博客项目这种内容型项目中，我并不是想看一个枯燥的404提示，我更想看的是我查询的关键字在没有反馈的内容时，开发者给用户的交互是一种什么样的实现，才能吸引用户停留在我的网站中。

比如，我查询一个色彩关键字，我的网站上没有相关的博客内容，但是我不能给你一个简简单单的404，而是给用户一些推荐内容的快捷入口，引导用户点击进入博客内容页面，留住流量。

而资源类的404，可以给一些动画，或者是引入腾讯404服务的交互，让服务器端的错误或者是资源缺失，给用户一种丰富、有趣的体验。

在最近有一个主题卖疯了，就是华为商城的宇航人主题，它不就是靠着有趣才吸引了消费者吗，在短视频中火了后，不知道多少人为了一个主题去买了一块手表。可见，现在C端产品考虑趣味性的比重应该是比较大的。

Empty 空状态

为了弥补我们网站内容的缺失和资源缺失，给用户带来的不良体验，我们需要优化的点就是做一个有意思的Empty 空状态展示页。

在Empty中，我设计的结构是，一个简单的动画吸引用户视线，一组类bilibili中的火星文，一组引流快捷入口，如下图：

定制型设计

我们在写作时，工具会提示让我们选择是否启用专注模式，专注模式就是一种定制型设计。再类比一下，我们使用网易云App时有精简模式和普通模式，精简模式下，只有控制按钮组其他的什么都没有。

所以，一个网站能不能够吸引用户长时间停留，最为关键的点大概就是有意义的丰富内容和有意思的交互。让用户觉得好玩，让他自己去浏览、去玩。这样的网站才能够保证回访率。

清新的结构和出彩的细节

单从设计结构来看，开发者可以给用户提供两套布局模式，比如：菜单固定在左的模型和菜单固定在顶部的模型。给用户提供两套视觉模型，Light型和Dark型，然后我们可以根据系统时间，默认给用户切换主题色。

或者，定义精简模式，在阅读模式下，减少系统相关的交互和按钮入口，新增一些阅读类型的按钮，比如：自定义行高、字号，自定义阅读模式下网站字色和背景色，有耐心的话，还可以给出一些国际化方案，例如，中英文切换或者是简繁体切换。

总之，需要我们动用一些时间和心血去做一些不一样的细节出来，把网站打磨的漂漂亮亮的，就可以比较大方的拿出去拉外快项目啦。

一个开发者的个人网站大概就是他的一个比较有特色的个人名片啦。我们前端开发者还是占据了大量的优势的，我们可以自己做一些自己想要的效果出来，我们自己就是自己项目的产品经理。

简洁而不简单，清新才是关键

在Antd的设计文档中，始终在着重描述三个设计思想：自然、高效和克制。始终在表达一种简简单单才是美。

在理想状态下，我们不太需要关注更多的细节，比如那个经典的撕逼话题：”你这个1像素能不能细一点点， 我看着就不像1像素“。相反我们需要去做减法，但是此减法非彼减法。视觉上的细节少了但是给开发的工作却多了。单是色彩就至少准备40多个，其看不见的工作就给了视觉上的简单赋予了另外的一种不简单。

做好一份设计并不是我以上描述的这么简单，有很多内容我们都不知道，毕竟不是专业的设计师，我了解的相关知识全部来自于书本。但是我们现在是从前端角度去分析一下下怎么去做设计，让我们的项目做得更好一点，更快一点，更简单一点。

简洁而不简单，把背后的工作留给自己慢慢品，把清新留给用户。