在 surge 的自定义策略组中，我设置了 github 策略组，并且设置了一个默认的策略组为 github，用于将所有 github 所有数据走当前的策略组。
而我将此策略组模式选择了 US 策略，以告之当前机器的 github 全部流量走 US 节点。
问题
问题在于我设置了 US 节点，但是没有任何作用，通过查看器观察到的流量还是走的默认节点。
分析
经过分析，发现 surge 的策略组是自上而下穿透的，因此需要将 github 策略组放在全局策略组之前。
]]>前几年刚开始折腾群晖的时候，我的思路其实很简单：
WebStation
+
Docker
+
Alias
例如：
/epg
/jellyfin
/ai
当时感觉非常合理，甚至会觉得：
这不就是网站部署吗？
但后来服务越来越多：
整个系统开始逐渐变得混乱。
最开始只是偶发页面不存在、静态资源 404、WebSocket 失败、反向代理异常。后来这些问题越来越明显，我才意识到：WebStation 更像旧时代 Web Hosting 的产物。
它非常适合：
但并不真正适合：
尤其是 Alias + 子路径 这个方案。
现代前端其实大量默认运行在：
/
而不是：
/subpath
于是：
/epg
/jellyfin
这种结构会天然开始和现代前端冲突。
我后来慢慢意识到，现代 Homelab 的核心已经不是“网站托管”，而是：
服务编排 + 网络系统
这其实是一个非常大的认知变化。
于是后来我开始逐渐迁移整个架构：
Cloudflare Tunnel
+
Reverse Proxy
+
Docker Compose
+
Tailscale
最终变成现在这套方案。
它可能不是最快的。但在家庭网络环境下，足够稳定。而稳定，其实远比“理论最快”重要。
过去很长一段时间，我在群晖上部署服务时，习惯使用：
WebStation
+
Alias
+
Docker
一开始看起来很方便。
但随着 React / Next.js、WebSocket、AI WebUI、Jellyfin、EPG 系统和 Docker 服务越来越多，问题也越来越明显：
后来我逐渐意识到，WebStation 更像“传统网站托管时代”的产物，而现代 Homelab / Docker / React 服务，其实已经是另一套体系。
于是我开始重新设计整个家庭服务器架构，最终形成了现在这套：
Cloudflare Tunnel
+
群晖 Reverse Proxy
+
Docker Compose
+
Tailscale
这篇文章主要记录：
这套方案适用于：
推荐架构是：
公网
↓
Cloudflare Tunnel
↓
群晖 Reverse Proxy
↓
Docker Services
架构图：
┌──────────────────┐
│ Browser │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Cloudflare Edge │
└────────┬─────────┘
│ Tunnel
▼
┌──────────────────┐
│ Synology NAS │
│ Reverse Proxy │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Docker Services │
│ EPG / Jellyfin │
│ Grafana / AI │
└──────────────────┘
核心思路很简单：公网入口交给 Cloudflare Tunnel，NAS 内部再用群晖 Reverse Proxy 转发到不同的 Docker 服务。
WebStation 更适合传统网站，例如：
它不太适合：
Alias 的典型写法是：
/epg
/jellyfin
/ai
但很多现代应用默认运行在：
/
而不是：
/subpath
因此会出现：
所以更推荐使用子域名。
推荐：
epg.matrixpunk.com
jellyfin.matrixpunk.com
ai.matrixpunk.com
不推荐：
matrixpunk.com/epg
matrixpunk.com/jellyfin
Tunnel 的本质不是：
公网主动访问你家
而是：
NAS 主动连接 Cloudflare
因此它不需要：
真实链路是：
用户
↓
Cloudflare Edge
↓
Cloudflare Tunnel
↓
群晖 Docker
这点对家庭宽带非常关键。很多家庭宽带没有公网 IPv4，80 / 443 入站端口也经常不可用。
Cloudflare Tunnel 解决的是“能稳定访问”的问题，不是“绝对高速”的问题。
Cloudflare Tunnel 很多时候仍然走国际线路，例如：
不同运营商、不同地区、不同时间段，体验会有明显差异。
cloudflared 默认可能使用 QUIC。QUIC 基于 UDP，而国内家庭宽带里 UDP 经常会遇到：
所以在家庭网络里，QUIC 不一定是最稳的选择。
Tunnel 更依赖：
NAS → Cloudflare
也就是家庭宽带的上传稳定性。上传带宽小、晚高峰抖动、运营商路由差，都会影响最终访问体验。
推荐配置：
--protocol http2
原因很直接：TCP 通常比 QUIC / UDP 更稳。
docker-compose.yml：
services:
cloudflared:
image: cloudflare/cloudflared:latest
container_name: cloudflared
restart: unless-stopped
network_mode: host
command: tunnel run --protocol http2 --edge-ip-version 4
environment:
- TUNNEL_TOKEN=你的TunnelToken
--protocol http2避免 QUIC 在国内网络下的不稳定。
--edge-ip-version 4国内很多宽带的 IPv6 质量反而更差，优先 IPv4 通常更稳。
network_mode: host群晖上推荐使用 host 网络模式，主要是为了避免：
restart: unless-stoppedNAS 重启后自动恢复，不需要手动启动 Tunnel。
进入：
https://one.dash.cloudflare.com
路径：
Networks
→ Tunnels
→ Create Tunnel
→ Docker
Cloudflare 会生成一段：
docker run ...
里面：
--token xxx
xxx 就是 Tunnel Token。
/docker
/cloudflared
docker-compose.yml
docker compose up -d
查看日志：
docker logs -f cloudflared
成功日志里会出现：
Registered tunnel connection
推荐：
Tunnel
↓
群晖 Reverse Proxy
↓
Docker Services
例如：
| 服务 | 本地端口 |
|---|---|
| EPG | 3000 |
| Jellyfin | 8096 |
| Grafana | 3001 |
| Portainer | 9000 |
DSM 路径：
登录门户
→ 反向代理
示例：
| 来源 | 目标 |
|---|---|
| epg.matrixpunk.com | localhost<3000> |
| grafana.matrixpunk.com | localhost<3001> |
Cloudflare Tunnel 只负责把请求送进 NAS，具体服务分发交给群晖 Reverse Proxy。这样每个服务都使用独立子域名，应用本身仍然运行在根路径 /。
推荐公网暴露：
不推荐公网暴露：
这些更推荐使用 Tailscale 访问。
长期架构可以按职责拆分：
| 职责 | 推荐方案 |
|---|---|
| 公网入口 | Cloudflare Tunnel |
| 内网管理 | Tailscale |
| 服务部署 | Docker Compose |
| HTTPS | Cloudflare |
| 反向代理 | 群晖 Reverse Proxy |
不推荐：
WebStation + Alias + Docker
推荐：
Cloudflare Tunnel
+
Reverse Proxy
+
子域名
+
Docker Compose
这是目前对群晖、HomeLab、家庭网络来说，长期更稳的方案。
推荐公网暴露：
epg.matrixpunk.com
blog.matrixpunk.com
ai.matrixpunk.com
推荐仅内网访问：
DSM
SSH
Portainer
数据库
这些通过 Tailscale 访问即可。
┌─────────────────────┐
│ Cloudflare DNS │
└─────────┬───────────┘
│
▼
┌─────────────────────┐
│ Cloudflare Tunnel │
└─────────┬───────────┘
│
▼
┌─────────────────────┐
│ Synology NAS │
│ Reverse Proxy │
└─────────┬───────────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ EPG Service │ │ Jellyfin │ │ Grafana │
│ Port 3000 │ │ Port 8096 │ │ Port 3001 │
└──────────────┘ └──────────────┘ └──────────────┘
Tunnel 的核心价值不是高速，而是稳定暴露家庭服务。
在家庭网络环境里，推荐：
尽量避免：
简单、可恢复、职责清晰，才是家庭服务长期稳定运行的关键。
]]>上一版 UI 更像一个轻量的个人主页。它基于 Next.js、Tailwind CSS 和 Shadcn UI，整体偏现代、克制，也有主题切换、View Transitions、圆形友链、MDX 内容这些功能。它并不差，甚至作为一个个人站已经够用了。
但问题也在这里：它更像一个“能用的博客系统”，而不是一个有明确识别度的个人内容入口。
这次我使用 AI 参与重构，并不是想让 AI 随便生成一个好看的页面，而是把它当成一个设计和工程协作对象：我给方向、约束和审美偏好，AI 帮我拆解问题、提出方案、修改代码、检查移动端和构建结果。最后留下来的不是某个一次性 prompt 的产物，而是一轮轮取舍之后的结果。
上一版 UI 的核心问题不是丑，而是信息优先级不够清晰。
首页更像一页个人简介，重点在头像、导航、简介和文章入口。读者当然可以继续点进去看文章，但首屏没有马上告诉读者：这里最近写了什么、有哪些笔记、有什么项目、这个站点的内容重心是什么。
对于一个个人博客来说，这种方式很常见，也很稳。但我后来发现，博客如果只停留在“自我介绍”，它会让内容被藏起来。每次访问首页，读者都要再多点一次，才能真正进入内容。
另外，上一版的视觉气质也偏通用。白底、卡片、柔和圆角、主题切换、常规导航，这些都很安全，但也容易让站点变成一个“还不错的模板”。我希望它更像自己的东西，而不是又一个技术博客主题。
这次我给首页定了一个方向：它首先要有强品牌识别，其次要立刻承接内容。
所以现在的首页保留了很大的 <EY /> 字标。它不是一个普通 logo，而是首屏最重要的记忆点。进入页面时，先让人知道这是 Ethan Young 的站点。
但它不能只是一张品牌封面。首屏高度被控制下来，让下方的 Dispatch 内容区在第一屏就露出一点。这样读者会知道：往下滚马上就是最近文章、短笔记和项目，而不是又一个单屏落地页。
新的首页更像一个内容调度台：
这套结构对我来说更合理。因为我的博客不是纯作品集，也不是纯简历页，而是文章、笔记、项目和生活记录混在一起的个人归档。
这次视觉方向参考的是 The Verge 式的编辑部气质：近黑画布、巨大字标、酸薄荷和紫色硬色块、1px 边框、mono 标签、扁平但很强烈的层级。
我喜欢它的一点是：它不靠阴影、渐变和玻璃拟态制造“高级感”，而是靠排版、边框、色块和信息节奏撑起来。
这和个人博客其实很搭。博客最重要的是内容，但内容也需要一个有态度的容器。暗色画布让页面更像一个编辑台，mint 和紫色则负责制造记忆点。卡片和边框不只是装饰，而是用来划分信息：哪些是文章，哪些是笔记，哪些是项目。
我也去掉了主题切换。之前我一直觉得博客应该有 light / dark mode，但这次改完发现，主题切换反而会稀释设计。当前首页的暗色不是一个模式，而是整个视觉系统的基础。强行做亮色版，意味着每个色块、边框、Logo、插画和 hover 状态都要重新推一遍，否则就会变成“能切换，但不好看”。
与其维护一个不完整的双主题，不如把单主题做好。
这次 AI 最大的价值不是写代码快，而是帮我持续做决策拆解。
如果只是说“帮我把首页改好看”，AI 很容易给出一堆通用建议：更大的 hero、更漂亮的卡片、更丰富的动效。但这些建议通常没有站点上下文，也不一定适合个人博客。
我这次的做法是不断给它更具体的约束：
有了这些约束之后，AI 更像一个可以一起推敲方案的前端搭档。它会先分析信息架构，再给出修改计划，然后落到 Astro 组件、Tailwind class、全局 CSS 和构建检查里。
当然，AI 也不是一次就对。比如主题切换按钮曾经显示不出来，点击也没有效果；Logo 颜色一开始也像照片负片；漫画人物放在首屏底部时，移动端存在压迫感。这些问题都不是靠一句 prompt 解决的，而是不断发现、判断、调整。
第一，AI 更适合在有明确方向时放大执行力，而不是替我决定审美。
如果我不给它设计系统、布局目标和判断标准，它很容易走向“通用 SaaS 首页”。但当我明确说这是个人博客、需要暗色编辑部风格、不要渐变光晕、不要恢复主题切换，它就能更稳定地沿着这个方向推进。
第二，重构 UI 不能只看首屏截图。
一个首页好不好，不只取决于 hero 漂不漂亮，还取决于首屏之后有没有内容接力，移动端会不会挤，Footer 会不会突兀，链接 hover 是否统一，文章列表、笔记列表、项目区是不是同一种语言。
第三，很多功能不是越多越好。
主题切换、动画、装饰图、复杂交互都可以让页面看起来更“完整”，但如果它们没有服务于内容，就会变成噪音。这次反而是删掉一些东西之后，首页更清楚了。
重构后的博客不是完美的，但它更接近我想要的状态。
它仍然是一个个人博客，但不再只是一个简单的个人主页。它有一个明确的视觉入口，也能马上看到最近内容；它保留了一些个性化装饰，但不会让装饰抢走信息；它有强烈的暗色风格，但没有为了炫技堆叠复杂效果。
更重要的是，这次改版让我重新意识到：博客不是一次搭好就结束的项目。它会随着我写什么、做什么、在意什么而继续变化。
AI 只是这次变化里的一个工具。真正决定博客长什么样的，还是我想怎样表达自己。
]]>一个常见的误区：Ctrl+b d 分离会话时需要先按 Ctrl+b 并松开，然后再按 d，而不是同时按下所有键。
# 安装 fzf (模糊查找工具)
brew install fzf
$(brew --prefix)/opt/fzf/install
# 安装 tmux
brew install tmux
# 安装 Oh My Zsh (可选，用于 shell 增强)
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
# 安装 TPM (tmux 插件管理器)
git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm
# 启用鼠标支持
set -g mouse on
# 历史记录行数
set -g history-limit 10000
# 窗口和面板索引从 1 开始
set -g base-index 1
setw -g pane-base-index 1
# 减少按键延迟
set -s escape-time 0
# 终端颜色支持
set-option -g default-terminal "screen-256color"
# 状态栏样式
set -g status-style bg=black,fg=white
set -g status-left-length 30
set -g status-right-length 150
# 左侧显示：会话名称
set -g status-left "#[fg=green]#S #[fg=yellow]|#[default]"
# 右侧显示：日期时间
set -g status-right "#[fg=cyan]%Y-%m-%d %H:%M:%S#[default]"
# TPM 插件列表
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'tmux-plugins/tmux-resurrect' # 会话保存/恢复
set -g @plugin 'tmux-plugins/tmux-continuum' # 自动保存会话
# 自动保存/恢复配置
set -g @continuum-restore 'on' # 启动时自动恢复
set -g @continuum-save-interval '5' # 每 5 分钟自动保存
# 修改前缀键为 Ctrl+a
unbind C-b
set-option -g prefix C-a
bind-key C-a send-prefix
# 分割窗口快捷键
bind | split-window -h # 垂直分割
bind - split-window -v # 水平分割
# 重载配置文件
bind r source-file ~/.tmux.conf \; display-message "Config reloaded!"
# 必须放在配置文件末尾
run '~/.tmux/plugins/tpm/tpm'
提示：首次使用时，进入 tmux 后按
Ctrl+a+I(大写) 安装所有插件。
# 常用命令简化
alias t='tmux' # 启动 tmux
alias tn='tmux new -s' # 创建新会话
alias ta='tmux attach -t' # 附加到会话
alias tls='tmux ls' # 列出会话
alias tk='tmux kill-session -t' # 删除会话
alias tka='tmux kill-server' # 关闭所有会话
alias tr='tmux rename-session -t' # 重命名会话
alias tw='tmux new-window -n' # 创建新窗口
alias tl='tmux list-windows' # 列出窗口
alias td='tmux detach' # 分离会话
# 智能附加/创建会话
tma() {
# 检查是否在交互式终端中
if [ ! -t 1 ]; then
echo "❌ 当前环境不是交互式终端，无法使用 fzf 选择"
echo "请在终端中运行 tma 命令"
return 1
fi
# 无参数时使用 fzf 选择会话
if [ -z "$1" ]; then
local session
session=$(tmux ls 2>/dev/null | awk -F: '{print $1}' | fzf --height 40% --reverse --border)
if [ -n "$session" ]; then
tmux attach -t "$session"
else
echo "未选择任何 tmux 会话"
fi
else
# 有参数时尝试附加，失败则创建新会话
tmux attach -t "$1" 2>/dev/null || tmux new -s "$1"
fi
}
# 使用 fzf 快速切换窗口
tmw() {
# 检查是否在交互式终端中
if [ ! -t 1 ]; then
echo "❌ 当前环境不是交互式终端，无法使用 fzf 选择窗口"
echo "请在终端中运行 tmw 命令"
return 1
fi
# 确认是否在 tmux 会话中
if [ -z "$TMUX" ]; then
echo "⚠️ 当前不在 tmux 会话中，请先进入 tmux 再使用 tmw"
return 1
fi
# 获取窗口列表并使用 fzf 选择
local target
target=$(tmux list-windows -F '#I: #W' | fzf --height 40% --reverse --border)
if [ -n "$target" ]; then
local win_id
win_id=$(echo "$target" | cut -d: -f1 | tr -d ' ')
tmux select-window -t "$win_id"
else
echo "未选择任何窗口"
fi
}
# 手动保存/恢复会话
alias tsave='tmux run-shell ~/.tmux/plugins/tmux-resurrect/scripts/save.sh'
alias trestore='tmux run-shell ~/.tmux/plugins/tmux-resurrect/scripts/restore.sh'
# 快速进入预定义会话
alias tdev='tmux attach -t dev || tmux new -s dev'
alias twork='tmux attach -t work || tmux new -s work'
alias tplay='tmux attach -t play || tmux new -s play'
# FZF 默认选项
export FZF_DEFAULT_OPTS='--height 40% --reverse --border --preview-window=down:3:hidden:wrap'
# FZF 文件搜索命令 (需要安装 fd)
export FZF_CTRL_T_COMMAND='fd --type f --hidden --follow --exclude .git'
# 创建或附加到名为 "work" 的会话
tma work
# 不带参数时弹出 fzf 选择器
tma
# 在 tmux 会话中使用 fzf 快速切换窗口
tmw
最近在开发一个 tmux 窗口快速切换功能时，遇到了一个有趣的问题：
# 定义了一个窗口切换函数
tmw() {
# 使用 fzf 选择并切换 tmux 窗口
local target=$(tmux list-windows -F '#{window_index}:#{window_name}' | fzf ...)
tmux select-window -t "${target%%:*}"
}
奇怪的是：
source ~/.zshrc 后，函数定义正常tmw 时，执行的仍是旧版本source ~/.zshrc，tmux 内部的函数也不更新外层 Shell (PID: 1000)
├── tmux server (PID: 1001)
├── tmux session "dev"
├── window 0: zsh (PID: 1002) ← 独立的 shell 进程
├── window 1: zsh (PID: 1003) ← 另一个独立的 shell 进程
└── window 2: vim (PID: 1004)
关键理解：tmux 中的每个窗口都运行着独立的 shell 进程，它们：
# 时间线分析
10:00 - 启动外层 shell，加载 ~/.zshrc (版本A)
10:05 - 进入 tmux，创建新 shell 进程，继承当时的配置 (版本A)
10:10 - 修改配置文件 (版本B)
10:15 - 外层 shell: source ~/.zshrc ← 只更新外层 shell 为版本B
10:20 - tmux 内运行函数 ← 仍使用版本A！
# 在 tmux 会话内执行
source ~/.zshrc
# 或者直接加载特定配置
source ~/.config/zsh/.tmux_cfg
优点：快速、精确 缺点：每个窗口都需要单独执行
# 退出当前会话
tmux detach
# 重新进入（会创建新的 shell 进程）
tmux attach -t session-name
优点：一次性解决所有窗口 缺点：中断当前工作流
# 向所有窗口发送重载命令
tmux send-keys -t session-name: 'source ~/.zshrc' C-m
# 或者写成函数
treload() {
local session="${1:-$(tmux display-message -p '#S')}"
tmux list-windows -t "$session" -F '#{window_index}' | \
while read window; do
tmux send-keys -t "${session}:${window}" 'source ~/.zshrc' C-m
done
}
优点：批量更新，不中断工作流 缺点：稍复杂，可能干扰正在运行的命令
# ~/.config/zsh/dev-utils.zsh
# 开发期间的快速重载函数
dev_reload() {
echo "🔄 重载配置..."
source ~/.zshrc
echo "✅ 配置已更新"
# 如果在 tmux 中，提醒其他窗口
if [[ -n "$TMUX" ]]; then
echo "💡 提示：其他 tmux 窗口需要手动重载"
fi
}
alias dr='dev_reload'
# 在 ~/.zshrc 中添加版本检查
export ZSH_CONFIG_VERSION="2024.01.27"
check_config_version() {
local expected_version="2024.01.27"
if [[ "$ZSH_CONFIG_VERSION" != "$expected_version" ]]; then
echo "⚠️ 配置版本过期，建议重载: source ~/.zshrc"
fi
}
# 在 tmux 窗口启动时检查
if [[ -n "$TMUX" ]]; then
check_config_version
fi
# ~/.tmux.conf
# 绑定快捷键快速重载所有窗口配置
bind R run-shell '\
for window in $(tmux list-windows -F "#{window_index}"); do \
tmux send-keys -t :$window "source ~/.zshrc" C-m; \
done; \
tmux display-message "已重载所有窗口配置"'
这个问题揭示了几个重要的系统概念：
类似的场景还出现在：
Tmux 的 shell 环境隔离是一个设计特性，不是 bug。理解这个机制有助于：
记住：修改配置后，别忘了在 tmux 内部也要重新加载！
]]>回头看这一年，整体状态基本维持原样。年初计划去做的一些事情，如今回想起来，可以说是几乎全军覆没。
时常会感叹：人生里的梦想铺得很大，而现实真正能施展的力量却始终有限。
生活上基本没有什么改变，依然是朝九晚五的工作节奏，偶尔加班，日子一天天往前走。
今年最大的变化，来自小朋友。慢慢长大，开始上幼儿园，生活的重心也随之发生了变化。外出游玩的次数比往年多了一些，大概去了三座城市，看了些不同的风景。
总体而言，生活依旧平稳。
技术上谈不上有什么突破，依然是熟悉的技术栈：前端为主，搭配一些后端工作。
这一年更多是在对过去的项目做升级和改造，让它们变得更稳定、更可维护，新的技术尝试并不多。
倒是慢慢学会了如何去 vibe coding。程序员这份职业有时候确实够”狠”——优化和重构起来，干掉过去的自己从不手软。
基本没怎么看书。
写作方面同样没有太多进展，博客更新频率依然偏低。
主要还是零散地写了一些技术文章，记录并分享工作中的经验。整体来看，输出依旧不多，离自己期望的状态还有不小的距离。
总体而言，2025 年过得相对平淡，没有明显的高峰，也没有太深的低谷。
希望 2026 年能在这种平稳之中找到一些新的可能。至于具体计划，这里就先不展开了——顺其自然吧。
]]>我叫 Ethan Young，也可叫 charles Young， 反正代号而已， 是一名常驻南京的前端 web 开发，博客地址是 https://ethanyoung.me。博客主要记录我的生活、分享技术、表达思考和见证成长。充当自己的树洞吧。
其实我并不擅长写作，表达能力也有限，加上性格偏内向。有时候觉得写博客就像是把自己的内心世界暴露在公共场合，仿佛在众人面前”裸奔”。但转念一想，观众本就不多，而且大家彼此并不熟悉。或许这种”坦诚相见”、剖析自我的过程，反而能让我更清楚地认识自己。
人生其中一道命题就是：我是谁？
你的经历，你自己的决定，决定了你是谁吧。
答案暂定吧～
我通常会在工作之余抽出时间来写作。使用 Obsidian 记录新的想法或经历，慢慢整理成一篇文章。
失去过；有过多次，但每次都能恢复；第一版博客因为成本问题，需要服务器，前端技术又不够成熟，页面各种 bug，放弃了；
第二版博客因为工作太忙，没时间维护，放弃了；
第三版，一直维持到现在
自己推荐博客是2024：转折与成长的一年
推荐你爱的是哪个国？ 虽然文章所阐述的部分观点我不认同，但文章还是不错的。
电视《异形：地球》，对于异形系列的科幻迷来说，这部剧集是一个不错的补充，剧情还行可看。
电影《超人》，将以前的超人由神降为了人，有点弱，剧情一般般；不是很好看
想做的事情很多，画画，摄影，骑行，或者做个小小的开源项目, 只是一直没有开始而已
人生路漫漫，做好自己
]]>学习 vim 时，其实就是尽量减少手指离开键盘的频率
其实入门简单，我是直接在控制台上面输入vimtutor，然后跟着教程一步步来。各个操作都可以在教程中找到。
问题点在于，实际使用中，总有些快捷键不记得。需要不断的进行去查找。
后来看到一款编辑器，叫 neovim，基于 vim 的改进版，支持插件系统，社区活跃。
试着去配置时，有种写代码感觉，本身配置语言就是 Lua，配置文件也可以像代码一样进行组织
但还是感觉很麻烦，看了一圈配置，最终还是选择 lazvim 进行一站式配置。
目前使用的 lazyvim 配置， 逐步熟悉 vim 操作，关键在于大量的练习，改变过去基于 vscode 按键肌肉记忆，有点难度。
在 surge 的自定义策略组中，我设置了 github 策略组，并且设置了一个默认的策略组为 github，用于将所有 github 所有数据走当前的策略组。
而我将此策略组模式选择了 US 策略，以告之当前机器的 github 全部流量走 US 节点。
问题在于我设置了 US 节点，但是没有任何作用，通过查看器观察到的流量还是走的默认节点。
经过分析，发现 surge 的策略组是自上而下穿透的，因此需要将 github 策略组放在全局策略组之前。
]]>循环依赖(Circular dependency)是指在模块系统中，两个或多个模块形成相互引用的依赖关系。这种情况会导致模块加载和初始化过程变得复杂且难以预测。
如下图所示，循环依赖可以是直接的相互引用，也可以是间接的依赖环：
flowchart TD
subgraph "循环依赖结构"
ModuleA((模块A)) -->|导入| ModuleB((模块B))
ModuleB -->|导入| ModuleA
end
subgraph "间接循环依赖"
ModC((模块C)) -->|导入| ModD((模块D))
ModD -->|导入| ModE((模块E))
ModE -->|导入| ModC
end
flowchart TD
subgraph "引发问题"
Problems[循环依赖] --> P1[未完成的对象初始化]
Problems --> P2[undefined值]
Problems --> P3[执行顺序不可预测]
Problems --> P4[调试困难]
end
flowchart TD
subgraph "模块加载过程"
Start[开始加载] --> LoadA[开始加载模块A]
LoadA --> A1[解析模块A的依赖]
A1 --> A2[发现模块A依赖模块B]
A2 --> LoadB[开始加载模块B]
LoadB --> B1[解析模块B的依赖]
B1 --> B2[发现模块B依赖模块A]
B2 --> Decision{模块系统如何处理?}
Decision -->|CommonJS| CJS[返回未完成的A]
CJS --> B3[完成模块B的初始化]
B3 --> A3[继续模块A的初始化]
A3 --> Done[加载完成]
Decision -->|ES Modules| ESM[完成构造阶段]
ESM --> ESM2[执行模块A代码]
ESM2 --> ESM3[执行模块B代码]
ESM3 --> Done
Decision -->|未处理| Error[运行时错误]
end
| 方法 | 示例 | 说明 |
|---|---|---|
| ✅ 延迟加载 | require() 写到函数内部 | 避免初始化阶段访问未定义 |
| ✅ 提取公共模块 | 建立 shared.js | A 和 B 不直接依赖彼此 |
| ✅ 重构依赖方向 | 抽象高层逻辑模块 | 减少相互耦合 |
当从工单列表进入工单详情时，导致页面展示空白。代码报错：
hook.js:608 TypeError: _pages_cashRegister_ThirdPlatformService_SinopecCompService__WEBPACK_IMPORTED_MODULE_16__.SinopecCompService is not a constructor
at ./src/pages/cashRegister/ThirdPlatformService/service.js (service.js:12:68)
at __webpack_require__ (bootstrap:853:1)
at fn (bootstrap:150:1)
at ./src/class/cashRegister/GatheringInfo.js (42.js:725:107)
at __webpack_require__ (bootstrap:853:1)
at fn (bootstrap:150:1)
at ./src/class/cashRegister/index.js (index.js:1:1)
at __webpack_require__ (bootstrap:853:1)
at fn (bootstrap:150:1)
at ./src/pages/cashRegister/ThirdPlatformService/SinopecCompService.js (42.js:3437:78)
overrideMethod @ hook.js:608
s2.f6yc.comnull/:1
错误日志中关键信息：
_pages_cashRegister_ThirdPlatformService_SinopecCompService__WEBPACK_IMPORTED_MODULE_16__.SinopecCompService is not a constructor
报错位置在：
at ./src/pages/cashRegister/ThirdPlatformService/service.js (service.js:12:68)
相关代码：
import { SinopecCompService } from '@/pages/cashRegister/ThirdPlatformService/SinopecCompService'
import { ChinaSinopecCashPayService } from '@/pages/cashRegister/ThirdPlatformService/ChinaSinopecCashPayService'
import { ChinaSinopecService } from '@/pages/cashRegister/ThirdPlatformService/ChinaSinopecService'
const serviceList = [
new SinopecService(),
new MasterTooService(),
new SinopecCompService(),
new ChinaSinopecCashPayService(),
new ChinaSinopecService(),
]
报错原因是SinopecCompService不是一个构造函数。我们尝试打印SinopecCompService：
报错信息表明SinopecCompService在被实例化时不是一个构造函数，实际上它在调用时是undefined。
我们将断点打到SinopecCompService对象上面：
得到以下的堆栈，分析调用问题：
./src/pages/cashRegister/ThirdPlatformService/service.js (service.js:13)
__webpack_require__ (bootstrap:853)
fn (bootstrap:150)
./src/class/cashRegister/GatheringInfo.js (42.js:725)
__webpack_require__ (bootstrap:853)
fn (bootstrap:150)
./src/class/cashRegister/index.js (index.js:1)
__webpack_require__ (bootstrap:853)
fn (bootstrap:150)
./src/pages/cashRegister/ThirdPlatformService/SinopecCompService.js (42.js:3437)
__webpack_require__ (bootstrap:853)
fn (bootstrap:150)
./node_modules/cache-loader/dist/cjs.js?!./node_modules/babel-loader/lib/index.js!./node_modules/cache-loader/dist/cjs.js?!./node_modules/vue-loader/lib/index.js?!./src/pages/newMaintain/pages/ViewDetail/index.vue?vue&type=script&lang=js& (NewMaintainDetailView.js:1028)
__webpack_require__ (bootstrap:853)
fn (bootstrap:150)
./src/pages/newMaintain/pages/ViewDetail/index.vue?vue&type=script&lang=js& (index.vue:1)
__webpack_require__ (bootstrap:853)
fn (bootstrap:150)
./src/pages/newMaintain/pages/ViewDetail/index.vue (index.vue:1)
__webpack_require__ (bootstrap:853)....
通过调用堆栈，分析出循环依赖路径：
从ViewDetail/index.vue开始，导入了SinopecCompService.js
然后SinopecCompService.js导入了Payment类from '@/class/cashRegister'
class/cashRegister/index.js中导出了GatheringInfo等模块
export { GatheringInfo } from './GatheringInfo'
export { GatheringConfig } from './GatheringConfig'
export { Payment } from './Payment'
export { CzkCard } from './CzkCard'
export { Coupon } from './Coupon'
GatheringInfo.js导入了service.js中的hiddenPayment
import { hiddenPayment } from '@/pages/cashRegister/ThirdPlatformService/service'
最后service.js又导入了SinopecCompService，从而形成了循环依赖
分析过程如图：
解决方法很简单：将原先从ViewDetail/index.vue开始导入SinopecCompService.js的逻辑移出去，打破循环依赖链。
如果通过群晖直接申请 Let’s Encrypt 证书，会提示证书申请失败，原因是国内的 Let’s Encrypt 服务器无法访问。
基本流程：
由于阿里云的证书有效时间是 1 月，所有每个月都得申请，太麻烦，因此我采取曲线救国的方式。
今天，打算开始着手 IPTV 项目的开发。服务端目前先实现最基本的功能，主要是资源的检测功能。待有更好的资源后，再逐步开发后续功能。
同时，我也计划对博客进行升级，增加”我看过的书籍”和”电影”这两个新功能板块。今天就正式开始！
其实我一直想买一台 Mac Mini，但又担心会造成性能浪费，毕竟家里通过 NAS 已经搭建了不少服务。不过 Surge 的网络管理功能确实很吸引我，这方面还是很心动的。
在开发过程中，我注意到博客在页面切换时存在明显的闪烁问题，这影响了用户体验。计划通过以下方式解决：
接下来的博客内容规划如下：
前几天在群晖上安装 jenkins 时，遇到了一些问题，记录一下。由于需要打包 docker 镜像同时通过 jenkins 进行部署。
此时我们需要映射群晖系统系统上的 docker.sock 文件，这样 jenkins 就可以使用 docker 命令。记住需要 root 用户，不然启动失败。
docker is not command；这个问题是因为 jenkins 容器中没有安装 docker 客户端，我们需要安装 docker 客户端。
群晖安装 jenkins 时，需要注意的几点：
一般我们在群晖上面安装 jenkins，会使用 docker 安装，这样可以方便的管理 jenkins 的版本，同时也不会影响群晖的其他服务。
安装 jenkins 的时候，需要映射 docker.sock 文件，这样 jenkins 可以使用 docker 命令，同时也可以使用 docker 命令启动其他容器。
/var/run/docker.sock:/var/run/docker.sock
TIPS: 安装 jenkins 的时候，需要安装 docker 客户端，这样 jenkins 可以使用 docker 命令，同时也可以使用 docker 命令启动其他容器。
我们首先进入 docker 容器，然后安装 docker 客户端
docker exec -it jenkins bash
安装 docker 客户端
apt-get update
apt-get install -y docker.io
安装完成后，我们可以使用 docker 命令
docker --version
这种情况有个问题，就是每次重启 jenkins 容器，都需要重新安装 docker 客户端。
我们可以通过流水线的方式，进行安装，但是需要注意的是，我们需要在 jenkins 的容器中安装 docker 客户端，这样我们可以使用 docker 命令。
pipeline {
agent any
stages {
stage('Install Docker') {
steps {
sh 'apt-get update'
sh 'apt-get install -y docker.io'
}
}
}
}
每次构建都会安装 docker 客户端，这样就可以使用 docker 命令。但是这种方式也有个问题，就是每次构建都会安装 docker 客户端，这样会浪费时间。
年初时，我调离原先的岗位来到公司待岗，准备转战新项目。从这一刻直到 5 月份，噩梦才刚刚开始。
项目接手后可以说是一穷二白：没有环境、没有代码仓库，更为恐怖的是需求不明确。有些需求连客户自己也不清楚，需要我们反向讲解。就这样，我们踏上了一条破船，准备扬帆起航。
我们团队最初由一个产品、两个后端、一个前端，外加一个待产的测试组成。项目开展一个月后，第一次考验来临。作为前端，我在完成与后端的接口对接后就开始独立开发。然而在开发完第一波需求页面，准备联调时，意外发生了——对接的后端同事要离职。
当然前期他和说过一次，毕业五年工资没涨，因此今天去提了一下，发现被拒绝了，于是准备走人。我寻思着这哥们儿走了之后，总得有人做他的活吧。就这样等了十五天，在这十五天后端的活硬生生的停滞了。我们的 leader 也在找解决办法，问了我一句：你会不会 java？我说我只看的懂一点，要是开发不太行。他说，这样啊，这个项目比较重要，而且实在找不到人了，这样你先写点，到时候公司给你部分奖金。我无法拒绝答应了，开始了磕磕绊绊的后端代码之路。
其实看了一波下来，发现功能不是很复杂，就是同步数据入库，难点在于对接系统的客户给的 api 文档不明确，导致很多字段对应不上。在此我也明白了那哥们儿不容易。总之一个坑。
还有个事儿，待产的测试回家生娃了，又来一个测试。我原以为已经黑暗了，没想到，至暗时刻才刚刚开始。一开始我们和测试讨论了下，先不用在意细节，我们先把大体流程跑通，这个很关键。可是测试像是生活在另个时空，完全就没有听我们的意见，每天过来就是盯着细节测试。什么这边颜色不对，那边按钮间距有点问题，一些无伤大雅的问题。后来我们也各退一步，不管了先让她测吧，反正到时候流程问题也会测试到。就这样我们测试流程就上来了。
等到交付时候的，环境出问题了。我们没有足够的机器，导致部署的时候一台环境完全不够用。问题影响呢就是客户完全看不了我们做的 demo，很多的问题。由于当前环境的不够用，外加没有人懂后端部署，由于本人有搭建自己的博客的经验，因此临时又担当部署系统的负责人。我被迫放弃现在手头的活花了三天时间，将测试环境搭建完成。
时间来到交付的阶段，问题累计是显而易见的。无法交付！功能没有打通。我们 4 个人之后开启了地狱般的加班模式。连续一周的通宵，那几天让我想到了什么叫生不如死，萌生离职的想法。在这样我的身体肯定是吃不消的。
也许上天的眷顾吧，一天别的项目需要一个资深前端，让我去面试了，那边很满意。让我尽快参与到项目中去。这边的工作我就全部交出。我就在接下来的几天编写交接文档和部署文档。这样在一周后我就投入了下个项目中，算是临时解脱了。
来到新团队后，一切都变得不同。不用加班，完成既定工作就能准时下班，不必承担额外工作。在这里，我学到了很多新知识（不仅仅是前端相关）。同事们都很专业，每个人都致力于将问题处理得尽善尽美。
我的问题处理思路也发生了改变：从原来的简单修复，转变为先理解问题的根本原因再进行修复。在开发需求时，更注重”可扩展性和面向对象”的思想。当时还和同事讨论为什么在前端逻辑中使用面向对象编程——虽然前端通常推崇函数式编程，但由于项目的”历史债务问题”（没有使用 TypeScript 进行类型定义），现在只能通过 class 方式来确保数据的一致性。再加上 Vue2 对 TypeScript 的支持有限，最终我们选择了这种折中的方案。
我将框架由原先的 Next.js 换成了 Astro，原因在于它更加方便、简洁、迅速。此外域名续费买了三年，算是作为接下来写博客的动力吧。
接下来博客还是持续更新，包括功能，也许我会增加模块：
迈入了典型的中年兴趣领域：
给自己立个 flag：完成一直想做的 IPTV 应用。虽然之前几次都半途而废，但 2025 年一定要推出第一个版本！
时光飞逝，白驹过隙。转眼间从校园毕业已有 10 年，从一个热血少年变成了一个略显发福的中年人。有时坐在阳台上，回想起当年在银杏树下的自己，不知是否曾经畅想过今天的模样。
生活在国内，在使用任何公共服务你都的需要备案; 而且备案的过程也是非常繁琐的， 因此在国外网站注册域名是一个非常好的选择。
一天早上邮箱收到如下信息：
原因是我的信息不完整，需要我提供一些信息。
想起来当时注册信息的时候，我确实没有填写真实的信息，因为我不想让我的信息泄露出去。
不知道如何解封，直接在回了一封邮件；寻问如何解封？ 用 chatGPT 写了封英文邮件；
原以为会要等几天，没想到几个小时过后，收到回复。
按照邮件给出的地址，填写相关信息，等了几个小时，域名就解封了。
在域名被封禁的情况下，域名管理界面是没有已经购买的域名的；
]]>基本样式参照了其中，可是对于其中黑暗模式切换，被深深的吸引了，如下：
当时在想，这个是怎么做到的，为何次动画如此丝滑，我得研究下；
放弃了～～～
直接吧啦源码，看到如下关键信息：
::view-transition-old(view-transition-name)
::view-transition-new(view-transition-name)
印象中，这段使用的是 View Transition API 中的内容；于是乎去翻阅各种文档；发现大佬这边文章 页面级可视动画 View Transitions API 初体验，大佬深入浅出详细说明了此 API 的作用以及使用；这里不做过多的说明；
mark：View Transitions API 简化了复杂动画的实现，无需手动处理位置计算或动画控制，尤其适合页面级的场景切换和动画增强。
document.startViewTransition() 开始动画。从上图显示效果而言，扩散是从一个点扩散到浏览器整体视窗；而视窗的最大半径我们可以通过鼠标点击或者 touch 事件来触发获取元素的 Element.getBoundingClientRect()：
const rect = this.themeLabel?.getBoundingClientRect()
boundingClientRect 包含两个 x 和 y，代码当前相对于视窗相对位置，借用 MDN 图：
而此时我们需要计算由我们点击位置向外扩散圆的半径；如下图：
const radius = Math.hypot(Math.max(x, innerWidth - x), Math.max(y, innerHeight - y))
Math.hypot 计算直角三角形的斜边长度，确保动画覆盖整个视窗。Math.max 确定从触发点到视窗边缘的最远距离，确保动画从中心点覆盖整个页面。innerWidthinnerWidth 是一个只读属性，返回窗口的文档显示区的宽度（以像素为单位）。它包括滚动条的宽度（如果有）。在计算动画扩散半径时，我们使用 innerWidth 来确定从触发点到视窗边缘的最远距离。
接下来我们定义动画绘画路径：
const clipPath = [`circle(0px at ${x}px ${y}px)`, `circle(${radius}px at ${x}px ${y}px)`]
clipPath 是一个数组，表示动画的起始和结束状态：
await document.documentElement.animate(
{ clipPath: currentTheme === 'dark' ? clipPath.reverse() : clipPath },
{
duration: 350,
easing: 'ease-out',
pseudoElement: currentTheme === 'dark' ? '::view-transition-old(root)' : '::view-transition-new(root)',
}
).finished
动画执行效果
clipPath）。::view-transition-new(root)。::view-transition-new(root)。结合上面的流程图，在 view-transition 之后，使用 pseudoElement 精细控制新旧主题之间的过渡。
最终代码如下：【本次使用的是 WebComponent 进行组件的抽取】
<script>
import { themeAtom } from "~/store";
class ThemeSwitcher extends HTMLElement {
private themeLabel: HTMLLabelElement | null = null;
private themeInput: HTMLInputElement | null = null;
constructor() {
super();
this.initTheme();
}
private getSystemTheme(): "light" | "dark" {
return window.matchMedia("(prefers-color-scheme: dark)").matches
? "dark"
: "light";
}
private initTheme(): "light" | "dark" {
const localTheme = window.localStorage.getItem("theme");
return localTheme === "auto"
? this.getSystemTheme()
: (localTheme as "light" | "dark") || "light";
}
private updateTheme(theme: "light" | "dark"): void {
document.documentElement.classList.toggle("dark", theme === "dark");
document.documentElement.style.colorScheme = theme;
document.documentElement.setAttribute("data-theme", theme);
this.themeLabel?.classList.toggle("swap-active", theme === "light");
themeAtom.set(theme);
}
private async animateThemeTransition(x: number, y: number): Promise<void> {
const currentTheme = this.initTheme();
const radius = Math.hypot(
Math.max(x, innerWidth - x),
Math.max(y, innerHeight - y)
);
const clipPath = [
`circle(0px at ${x}px ${y}px)`,
`circle(${radius}px at ${x}px ${y}px)`,
];
try {
await document.documentElement.animate(
{ clipPath: currentTheme === "dark" ? clipPath.reverse() : clipPath },
{
duration: 350,
easing: "ease-out",
pseudoElement:
currentTheme === "dark"
? "::view-transition-old(root)"
: "::view-transition-new(root)",
}
).finished;
} catch (error) {
console.error("Animation failed:", error);
}
}
connectedCallback(): void {
this.themeLabel = this.querySelector("label");
this.themeInput = this.querySelector("input");
if (!this.themeLabel || !this.themeInput) {
console.error("Required elements not found");
return;
}
const currentTheme = this.initTheme();
this.updateTheme(currentTheme);
this.themeInput.addEventListener("click", async (event) => {
const currentTheme = this.initTheme();
const newTheme = currentTheme === "dark" ? "light" : "dark";
try {
const transition = document.startViewTransition(async () => {
this.updateTheme(newTheme);
window.localStorage.setItem("theme", newTheme);
});
await transition.ready;
const rect = this.themeLabel?.getBoundingClientRect();
if (rect) {
await this.animateThemeTransition(rect.x, rect.y);
}
} catch (error) {
console.error("Theme switch failed:", error);
// 回退方案
this.updateTheme(newTheme);
window.localStorage.setItem("theme", newTheme);
}
});
}
disconnectedCallback(): void {
this.themeInput?.removeEventListener("click", () => {});
}
}
customElements.define("switch-theme", ThemeSwitcher);
</script>
时常迷茫，不知前路何在，亦不晓心之所欲。倒不如停下脚步，将喧嚣隔绝，静心回望，细细品味那曾踏过的泥泞与辉煌。人这一生，是否必须不停向前？也许，并不需要。偶尔坐下来，倚一片青山，看众人行过，听风吹叶落，或许便是另一种圆满。
我不求同行者，不愿奔波争渡。只想独自坐在岁月的岸边，看时间从指间悄然流走，在沉静中，让心灵与天地共老。
]]>想象一下，你要搬家，却不想一件件搬所有的家当，而是把所有东西都装进一个统一的箱子，不管目的地是哪个城市，随时打开箱子就能继续生活。Docker 就是这样的”箱子”！它是一种开源的容器化技术，可以把应用程序和它需要的环境”打包”起来，让它能随时随地跑起来，无需担心”跑不动”。
Docker 的主要特点包括：
这里借用图片 bytebytego
Dockerfile 是一个文本文件，包含了一条条的指令（Instruction），每一条指令构建一层，因此每一条指令的内容都会对镜像产生影响。Dockerfile 的基本格式如下：
# Base image
FROM node:14 # 指定基础镜像
# Author
MAINTAINER matrixpunk <
# Set working directory
WORKDIR /app # 设置工作目录
# Copy source code
COPY . /app # 拷贝文件
# Install dependencies
RUN npm install # 安装依赖
# Expose port
EXPOSE 3000 # 暴露端口
# Start app
CMD ["npm", "start"] # 启动命令
docker build -t my-node-app .
docker run -d -p 3000:3000 my-node-app
运行 docker 容器时，可以使用
-d参数让容器在后台运行，-p参数指定端口映射。 剩余参数如下：
-i：以交互模式运行容器-t：分配一个伪终端--name：指定容器名称-v：挂载数据卷--rm：容器停止后自动删除
docker ps -a
docker stop <container_name>
docker rm <container_name>
docker ps
docker ps -a
docker ps -a
docker images
docker rmi <image_name>
docker pull <image_name>
docker push <image_name>
docker inspect <container_name>
docker logs <container_name>
docker exec <container_name> <command>
docker exec -it <container_name> /bin/bash
当我们使用 docker 构建多个镜像时，我们可以使用 docker-compose 来管理多个容器
如果你的项目涉及多个容器，比如一个跑应用、一个跑数据库，那么你需要 Docker Compose。它像一本多菜谱的菜单，一键可以上齐所有菜。
通常用于本地开发环境，生产环境建议使用 Docker Swarm 或 Kubernetes。
确保当前目录存在 docker-compose.yml compose.yml 文件 10.10.10.10 服务器的 docker-compose.yml 文件在/home/ocs/docker 目录下
version: '3' # 版本
services:
sample: # 服务名
build: # 构建镜像目录
context: ./
dockerfile: ./docker/Dockerfile
args:
NODE_ENV: production
restart: always # 是否重启之后进行重启
image: sampleName # 镜像名
ports: # 端口
- 3007:80 # 映射端口方式 -> 主机端口:容器端口
container_name: sampleNameContainer # 容器名
environment: # 环境变量
- NGINX_PORT=80
- API_ENV=api
- API_URL=http://10.10.10.10:8081/horizon/
- NODE_ENV=production
- WEBAPP=horizon
volumes: # 映射路径地址 -> 主机路径：容器路径
- /home/nginx/conf.d:/etc/nginx/conf.d
command: /bin/sh -c "envsubst '$$API_ENV,$$NGINX_PORT,$$API_URL,$$WEBAPP' < /etc/nginx/conf.d/https.template > /etc/nginx/conf.d/default.conf && exec nginx -g 'daemon off;'" # 启动命令
networks: # 虚拟网络名字
- app-net
networks:
app-net:
external:
name: app-net
docker-compose start 服务名
docker-compose stop 服务名
docker-compose rm 服务名
docker-compose build 服务名
docker-compose up -d 服务名
docker-compose logs --tail 500 服务名
最近在使用ncc 打包编译 nestjs，由于 nestjs 使用 hbs 作为模版引擎。
原先官网样例：
npm install --save hbs
import { NestFactory } from '@nestjs/core'
import { NestExpressApplication } from '@nestjs/platform-express'
import { join } from 'path'
import { AppModule } from './app.module'
async function bootstrap() {
const app = await NestFactory.create<NestExpressApplication>(AppModule)
app.useStaticAssets(join(__dirname, '..', 'public'))
app.setBaseViewsDir(join(__dirname, '..', 'views'))
//直接使用设置模版
app.setViewEngine('hbs')
await app.listen(3000)
}
bootstrap()
这样通过 ncc 编译，会存在丢失问题：
因此做如下设置即可：
import { NestFactory } from '@nestjs/core'
import { NestExpressApplication } from '@nestjs/platform-express'
import { join } from 'path'
import { AppModule } from './app.module'
import * as HBS from 'hbs'
async function bootstrap() {
const app = await NestFactory.create<NestExpressApplication>(AppModule)
app.useStaticAssets(join(__dirname, '..', 'public'))
app.setBaseViewsDir(join(__dirname, '..', 'views'))
//手动重写
app.set('view engine', 'hbs')
app.engine('hbs', HBS.__express)
await app.listen(3000)
}
bootstrap()
通过将其引入，再次编译即可。
]]>2003 年非典的时候，我还在上小学，印象很深。每天进学校，老师都会拿着电子温度计给我们测体温。那时候，非典传播得很快，很多人感染了，新闻里说病毒是因为有人吃野味传播的。大家都很害怕，不敢出门，也不敢去人多的地方。记得老爸那时想从外地回家，奶奶硬是把他劝住了。
现在听到类似的消息，心里也不免有些担心，怕会像 2003 年一样，病毒快速传播，很多人受影响。
微博上看到不少人对李文亮先生的指责，说他散布谣言，但我觉得他只是出于好意，提醒大家注意防护。这些指责好像都没有真正的依据，只是站在一种权威的立场上批评他。
我当时就和老婆说，先去买些口罩吧，毕竟多做准备总没坏处。
]]>在面对不确定的信息时，与其急于否定，不如多一分审慎和反思，毕竟防患于未然远比亡羊补牢来得重要。
最近几天想想，时间过的真快啊，再过两年三十了，都说是三十而立。可是总感觉在某些自己还没有准备好。比如说自己工资还赶不上花销。好像这一年所有的事情都在催着往前走！像是一头被鞭子抽了之后的疯牛，漫无目的，口吐白沫；疯狂地撒丫子向前狂奔。
这一年计划，想想完了 90%，这里心里还有些欣慰！
有时候发现，年龄越大，认识的事情方式也随着改变。看到一些不爽的事物，在以前总会义愤填膺。现在想想，何必呢，有些事情你是无法改变的；还不如顺其自然，人嘛！对得起自己，问心无愧吧。
就在前一天，自己还想着减肥呢。可是懒啊！只能慢慢来了。
去年过年前夕，在老丈人家举办了婚礼。原本打算把领取结婚证日子往后拖拖，可是父母一直在那儿催着，没办法啊。
这天，天空灰蒙蒙的，还是很冷。于是早上起了大早，喊上了思思，走领证去。
骑着老妈的小电驴，以 30 迈的速度晃悠悠的向着民政局走着！到了民政局，本以为会像电视剧里面一样：去排队号，等待叫号递交材料，宣誓，最后盖上钢印。工作人员会说一下：恭喜二位哈。
看来是我想多了，在我们还没有照相时，还没有等我们坐好，一张照片就好了，我俩还没有整理呢。太快了！然后收取了一个强制购买盒子。妈蛋啊！50 啊。
不过不去想这么多了，因为迈入了一个里程了！我结婚了。
怎么说呢，不怎么喜欢这个日子；刚刚过完五一假，然后再去请婚假，而且好多亲朋好友都得要请个假才能过来，怪麻烦人家的！奈何没有办法，老妈算的日子啊。
其实我一直认为婚礼就是过个形式，有没有都无所谓的；主要大家在一起吃个饭就行。后来我发现我错了。
生活中，有时候还是需要一些仪式感
白天零零碎碎的忙碌，都是为晚上正餐做准备的。
晚上，婚礼开始了；参加过好多别人的婚礼，没有想过自己的婚礼会是什么样式。晚宴之前，司仪把我俩叫过去，去对流程。
… 说了很多，没怎么记得。因为有点紧张，手心一直在冒汗。交流结束，还好老婆在旁边提醒着，稍微记得一些。晚上接近八点，婚礼开始了。
在她牵着父亲的手，来到我身边时。
也许是旁边音乐的原因
也许是朋友的祝福
或许是现场的气氛
那一刻我明白，我明白了我守护的人，余生的牵绊的人，就是她了。我的妻子！
那一刻，说实话我差点儿就哭了。只不过我忍住了。
其实我是想去看山的，而她要去看海；综合对比了下家庭地位，我输了！当然了看海就去三亚，毛里求斯等地方了，由于办理签证需要时间，加上的咱的假期就剩下 12 天了。最终决定了去三亚。
飞机 😄
长这么大，还没有坐过飞机，因此还有些期待！嗯！期待着上天！
原本原为飞机以为飞机应该和电视剧里面一样是那种大飞机！可事实呢。好小啊。
算了！！
飞起~~~~
嗯~~ 天很蓝，没有雾霾，我喜欢！
呼呼了两个小时，我们来到了三亚。下完飞机！走在的沿海的沙滩上面。哇！真的是海天一色。
第二天
来到蜈支洲岛
感受到了三亚的太阳，真毒！就昨天下飞机后三个小时，我的脚背已经晒伤了！
下午看了下三亚千古情：
晚上吃了一顿海鲜大餐(其实我内心在说，真少，不够吃啊)：
第三天
我们早上来到了玫瑰谷，感觉这里不像是景区，倒是人家的产业园。
各种各样的玫瑰，顺便科普到一个知识：玫瑰和月季，其实是同一个物种！有点惊讶。
白玫瑰
红玫瑰
上了一座山，具体不知道叫啥，站在山上看海吧！！
拽根的雕塑
亚龙湾，好多水上运动，很可惜没有玩啊
晚上，坐着大船看看，经典建筑
第四天，早早的起床，去南山（佛教圣地）
只让拍这里。。。。。
下午，我们来到了天涯海角,貌似是海南的最南端了
让她很自然的笑
就这样的第四天行程结束！意味着三亚之行也就结束了。
坐飞机回家~~~~~~好累啊
趁着夜色的降临
结束了这一次的旅程！！！
不过还有一点；就是很累啊！😩
其实买车子，原本不再考虑范围的，但是考虑到老丈人家，比较远。大过年的拎着东西回家，很不方便。于是乎着手去买车。
或许因为自己的不太懂车，买车的速度堪比买鞋了！快，😄
买车的全程都是销售帮我看，算账啊。我们俩客客气气的，弄的销售都有点不好意思。不过感觉遇到了一个好人吧。好多注意点，销售都帮我们处理的比较好。没有任何担心！
第一次开车，
老婆在旁边全程紧张 😱，能够明显感觉出来，她说话的语气有点抖！好在，本人开车比较稳。慢悠悠的开回家了。
消息
新房拿到手，大家都会着手装修；即便是精装修都会稍微整修一下。然而从这次装修中，总有了一些不愉快的经历！
9 月 30 日，开发商那边打电话，说是我们可以拿房了。由于前期看过样板房，所以这次拿房新鲜感就很少。
前期没有多少的电话，😔 从各个风声中传来我们是最后一批交房，心里咯噔一下；是不是因为我们前期闹装修问题，闹的太狠，导致这次把我们安排在最后一批？
拿房
9 月 30 日，起了个大早，晃晃悠悠的坐上地铁，匆匆赶到了新家，密密麻麻的楼群。
拿着一个箱子，里面钥匙啊，合同啊，遥控器什么的，全部都放在里面。感觉还是蛮方便的。
就进去验房了。
反正我不喜欢这样的精装修，于是和家里人商量下，我们稍微整修一下。
目前还在装修中，不过看着房子一天一天的朝着自己构想在变化，还是很满意的！
2018 年，年初列了一个计划清单，现在上面基本上完成的差不多了。
整一年都是很忙碌，都是在奔跑中。
2019 年的计划还没有列出来。
总之写到这里，不知道写是不是年终总结了，不纠结了。就当是给自己做个汇报吧！
2018 年 886~~ 😄
2019 年 见
]]>