工程 on 404_@林达

DigitalPlat 免费域名配置教程：从领取到 Cloudflare 解析

Wed, 03 Jun 2026 12:00:00 +0800

这篇文章记录一次从零领取免费域名并接入 Cloudflare 的过程。示例域名使用 linsk27.dpdns.org，平台是 DigitalPlat FreeDomain，DNS 托管使用 Cloudflare。

免费域名适合学习、测试、个人项目展示和临时服务入口。真正重要的生产项目，还是建议使用自己购买并长期持有的独立域名，方便迁移和品牌沉淀。

准备工作

开始之前需要准备三样东西：

一个 DigitalPlat Domains 账号
一个 Cloudflare 账号
一个想注册的域名前缀，例如 linsk27

本文示例最终得到的完整域名是：

`1`	`linsk27.dpdns.org`

如果你想用自己的名字，可以把 linsk27 换成其他前缀。前缀尽量使用小写字母、数字和短横线，避免使用商标、敏感词或容易被误判滥用的词。

第一步：在 DigitalPlat 里检查域名

在注册页面里填写：

1
2

Domain: linsk27
Suffix: .dpdns.org

然后勾选服务条款，点击检查可用性。

如果页面提示可用，就可以进入下一步。.dpdns.org 通常适合免费测试使用；如果选择其他后缀，可能会遇到 slot、订阅或 key 的限制，以页面实际提示为准。

第二步：先去 Cloudflare 添加站点

DigitalPlat 在注册时会要求填写外部 nameserver，所以需要先在 Cloudflare 里添加这个域名。

进入 Cloudflare 控制台，点击 Add a site，输入完整域名：

`1`	`linsk27.dpdns.org`

套餐选择 Free plan 即可。添加完成后，Cloudflare 会分配两个 nameserver，格式一般类似：

1
2

gerardo.ns.cloudflare.com
sue.ns.cloudflare.com

注意：这里的 nameserver 每个账号或域名可能不同，实际使用时要复制 Cloudflare 页面上给你的两个地址。

第三步：回 DigitalPlat 填写 nameserver

回到 DigitalPlat 的注册弹窗，把 Cloudflare 给出的两个 nameserver 填进去：

1
2

NS1: gerardo.ns.cloudflare.com
NS2: sue.ns.cloudflare.com

其他 NS 输入框可以留空。不要填写 ns1.digitalplat.net、ns2.digitalplat.net 或类似 DigitalPlat 自己的 nameserver，因为当前注册流程要求使用外部 nameserver。

Delegation mode 保持：

`1`	`External nameservers only`

然后选择 Use Free Slot，点击 Register。

注册成功后，DigitalPlat 的域名列表里应该能看到这个域名。进入管理页后，可以看到注册日期、到期时间和当前 nameserver。

第四步：等待 Cloudflare 检测生效

回到 Cloudflare 的域名 Overview 页面，会看到类似提示：

`1`	`Waiting for your registrar to propagate your new nameservers`

这是正常状态。点击 Check nameservers now 可以手动触发检查。

通常几分钟到几小时内会生效，最长可能需要 24 小时。只要 DigitalPlat 里已经保存了 Cloudflare 的两个 nameserver，就耐心等待即可。

也可以用命令检查 NS 是否已经切换：

`1`	`nslookup -type=ns linsk27.dpdns.org`

如果结果里出现 Cloudflare 的 nameserver，说明 NS 委派已经生效。

第五步：在 Cloudflare 添加 DNS 解析

Cloudflare 激活后，进入左侧 DNS 页面，添加解析记录。

如果你有服务器 IP，可以添加 A 记录：

Type: A
Name: @
IPv4 address: 你的服务器 IP
Proxy status: Proxied 或 DNS only

如果你想让 www 也能访问，可以再添加一条 CNAME：

1
2
3

Type: CNAME
Name: www
Target: linsk27.dpdns.org

如果你要绑定 GitHub Pages，可以使用 CNAME 指向：

1
2
3

Type: CNAME
Name: @
Target: linsk27.github.io

GitHub Pages 侧也需要在仓库设置里绑定自定义域名，否则只做 DNS 解析还不够。

第六步：配置 SSL/TLS

Cloudflare 激活后，进入 SSL/TLS 页面。

如果你只是用 GitHub Pages、Vercel、Netlify 这类静态托管，通常保持 Cloudflare 默认设置即可。

如果你自己有服务器，建议：

有 HTTPS 证书：使用 Full 或 Full (strict)
没有 HTTPS 证书：先配置证书，不建议长期使用 Flexible

Flexible 看似方便，但它只加密用户到 Cloudflare 的连接，Cloudflare 到源站之间仍可能是 HTTP，不适合长期使用。

常见问题

1. DigitalPlat 注册时报 403

先检查 nameserver 是否只填了 Cloudflare 给你的两个地址。不要把 ns3.digitalplat.net 或其他 DigitalPlat hosted DNS 填进去。

推荐配置：

1
2
3

NS1: Cloudflare 给你的第一个 nameserver
NS2: Cloudflare 给你的第二个 nameserver
NS3-NS8: 留空

如果仍然 403，可以刷新页面、重新登录后再提交一次。

2. Cloudflare 一直显示等待 nameserver

确认 DigitalPlat 的域名管理页里已经保存了 Cloudflare 的 nameserver。

如果保存没问题，那就是 DNS 委派还在传播。可以过几分钟再点 Check nameservers now，或者等待更久。

3. 域名注册成功但打不开网站

注册成功只代表域名属于你的账号，还需要在 Cloudflare 里添加 DNS 记录。

至少需要一条 A 记录或 CNAME 记录，否则浏览器不知道这个域名要指向哪里。

4. 是否需要开启 WHOIS Privacy

建议开启。免费域名注册时通常会填写姓名、邮箱、地址、电话等 WHOIS 信息，开启隐私保护可以减少个人信息暴露。

在 DigitalPlat 的域名管理页里找到 WHOIS Privacy，按页面提示启用即可。

总结

整个流程可以理解成三步：

在 Cloudflare 添加完整域名，拿到两个 nameserver
在 DigitalPlat 注册免费域名，并把 Cloudflare nameserver 填进去
等 Cloudflare 激活后，添加 A 记录或 CNAME 记录

完成后，linsk27.dpdns.org 就可以作为个人项目、测试服务或博客入口使用了。

ProofPR PR 证据检查器

Sat, 09 May 2026 00:00:00 +0000

ProofPR 是一个面向 Pull Request 审查的 GitHub Action 和 CLI。它的目标不是替代维护者，而是把 PR 里容易被忽略的证据信号先整理出来，让 review 更快进入重点。

适合谁

需要快速判断 PR 风险的开源维护者。
想给仓库增加 PR evidence scanning 的团队或个人项目。
关注 secrets scanning、dependency review、CI permissions 和 MCP security 的开发者。
经常 review AI generated code，希望先看风险信号再看实现细节的人。

项目价值

ProofPR 会把 Pull Request 中的多类信号整理成报告，包括 secrets 线索、依赖变化、GitHub Actions 权限、MCP 安全风险和维护者需要优先看的 review 线索。这样做的核心价值是减少重复检查，让维护者更容易判断一个 PR 是否需要补证据、补测试或调整权限。

如果你搜索的是 PR review automation、GitHub Action for pull request review、pull request evidence scanning、AI generated code review 或 GitHub Actions security，这个项目就是对应入口。

技术方向

GitHub Action
CLI
TypeScript / JavaScript
Pull Request diff 分析
Secrets 检测
依赖风险检查
CI 权限检查
MCP security 线索整理

项目入口

GitHub 仓库：linsk27/proof-pr
项目总览：linsk27 Projects

如果这个项目对你的 PR review 工作流有帮助，欢迎在 GitHub 仓库点 Star。Star 是我判断后续规则和报告质量优先级的主要依据。

AI Vue Flask Blog 全栈系统

Tue, 10 Mar 2026 00:00:00 +0000

AI-Vue3-python-flask-Blog 是一个 Vue 3、Flask、MySQL 和 AI 能力组合的全栈博客系统。它覆盖前端页面、后端接口、数据库持久化、内容管理和 AI 能力接入，适合作为课程设计、毕业设计、全栈项目练习和二次开发基础。

适合谁

需要 Vue 3 + Flask + MySQL 全栈项目参考的学生或初级开发者。
正在准备课程设计、毕业设计或项目答辩的人。
想学习前后端分离、接口设计、内容管理和数据库持久化的人。
想在传统博客系统里加入 AI 能力的人。

项目价值

这个项目的核心价值是完整。它不是只有一个前端页面，也不是只有接口示例，而是把页面、接口、数据和内容管理串成一个可继续扩展的系统。对于搜索 Vue Flask full stack project、Vue3 Flask MySQL blog system、AI blog system、graduation project 或 course design 的人，它能提供更直接的参考。

技术方向

Vue 3
Flask
Python
MySQL
Element Plus
前后端分离
内容管理
AI blog system

项目入口

GitHub 仓库：linsk27/AI-Vue3-python-flask-Blog
线上演示：ai-vue3-python-flask-blog.vercel.app
项目总览：linsk27 Projects

如果这个全栈项目对你有参考价值，欢迎在 GitHub 仓库点 Star。Star 是我继续完善文档、部署说明和二次开发示例的主要信号。

初步接触Docker

Tue, 03 Jun 2025 00:58:55 +0800

Docker 笔记：常用命令整理

镜像管理

查看镜像：docker images
拉取镜像：docker pull xxx
删除镜像：docker rmi xxx

容器管理

查看容器：docker ps / docker ps -a
进入容器：docker exec -it 容器名 bash
停止容器：docker stop 容器名
删除容器：docker rm 容器名

docker-compose 常用

启动：docker-compose up -d
停止：docker-compose down
查看：docker-compose ps
拉镜像：docker-compose pull

常用组合示例

docker run -d -p 8080:80 nginx
docker exec -it my-container bash
docker-compose up –build

清理空间

docker system prune -a

我的fre123部署流程

以阿里云为例

容器部署

# 回到 home 目录，确保路径正确
cd ~

# 克隆项目
git clone https://github.com/fre123-com/fre123-nav.git

# 进入 deploy 目录（docker-compose.yml 文件所在）
cd fre123-nav/deploy

# 拉取镜像
sudo docker-compose pull

# 启动服务
sudo docker-compose up -d

成功部署

[root@iZbp15al0g417943ohz4h1Z deploy]# docker-compose ps
WARN[0000] /root/fre123-nav/deploy/docker-compose.yaml: version is obsolete 
NAME               IMAGE                               COMMAND                   SERVICE            CREATED          STATUS         PORTS
fre123-mongo       mongo:3.6                           "docker-entrypoint.s…"   fre123-mongo       10 seconds ago   Up 7 seconds   0.0.0.0:27077->27017/tcp, :::27077->27017/tcp
fre123-nav-admin   fre123dev/fre123-nav-admin:v0.1.0   "/bin/bash nginx_sta…"   fre123-nav-admin   10 seconds ago   Up 7 seconds   0.0.0.0:3001->80/tcp, :::3001->80/tcp
fre123-nav-api     fre123dev/fre123-nav-api:v0.1.0     "pipenv run api pro"      fre123-nav-api     10 seconds ago   Up 6 seconds   0.0.0.0:8765->8765/tcp, :::8765->8765/tcp
fre123-nav-web     fre123dev/fre123-nav-web:v0.1.0     "/bin/sh start.sh"        fre123-nav-web     10 seconds ago   Up 7 seconds   0.0.0.0:3000->3000/tcp, :::3000->3000/tcp

下一步：浏览器访问

你可以现在在浏览器访问以下地址：

1
2

http://<你的阿里云服务器公网IP>:3000     # 主站前端
http://<你的阿里云服务器公网IP>:3001     # 管理后台

注意：确保端口已在阿里云安全组开放如果访问不了，可能是安全组没放行这些端口：

3000（前端）
3001（管理后台）
8765（后端 API，如果你需要访问）
27077（MongoDB 端口，通常不建议暴露）你可以登录阿里云控制台 → 安全组找到对应实例的安全组，手动添加规则（其他服务器同理）

服务器防火墙设置除了要在阿里云开放安全组，你还需要设置服务器本地防火墙开放，具体操作步骤可查看初步接触Nginx的文章

🐳 Nuxt 博客项目从 Windows 上传到阿里云服务器并用 Docker 部署上线教程

本教程适用于：在 Windows 本地开发 Nuxt 3 项目，在阿里云服务器（Linux）上通过 Docker 打包、运行并对外提供服务。

前置条件

本地开发环境（Windows） 上已有一个可正常构建的 Nuxt 3 项目。
阿里云服务器（推荐 CentOS 或 Ubuntu）已安装 Docker（无需本地安装 Docker）。
拥有服务器的 SSH 登录权限（FinalShell、XShell、PuTTY 等工具）。
（可选）已注册 Docker Hub 账号，用于推送镜像分享给他人。

将项目上传到阿里云服务器

方法一：FinalShell 右键上传

打开 FinalShell，连接到你的阿里云服务器。
在左侧文件管理器中定位到本地项目文件夹。
右键选中项目根目录，选择 “上传到服务器”，目标路径可选 /root/nuxt-blog。

方法二：命令行 `scp`

1
2

# 在 Windows PowerShell 或 Git Bash 中运行：
scp -r C:/path/to/your/nuxt-blog root@<服务器IP>:/root/nuxt-blog

在服务器上编写 Dockerfile

SSH 登录服务器：
1

ssh root@<服务器IP>
进入项目目录：
1

cd /root/nuxt-blog

创建并编辑 Dockerfile（适用于Nuxt3）：

# ---------- 构建阶段 ----------
FROM node:18 AS builder

# 设置工作目录
WORKDIR /app

# 增加 Node.js 可用内存（防止内存不足）
ENV NODE_OPTIONS="--max-old-space-size=3072"

# 拷贝依赖配置并安装
COPY package.json yarn.lock ./
RUN yarn install

# 拷贝全部项目源码
COPY . .

# 避免 nuxt 权限问题
RUN chmod +x node_modules/.bin/nuxt

# 构建项目
RUN node_modules/.bin/nuxt build

# ---------- 运行阶段 ----------
FROM node:18 AS runner

# 设置工作目录
WORKDIR /app

# 仅复制必要文件，减小镜像体积
COPY --from=builder /app/.output .output
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./

# Nuxt 默认端口
EXPOSE 3000

# 启动服务
CMD ["node", ".output/server/index.mjs"]

构建 Docker 镜像

在项目根目录执行：

1
2

# <用户名> 换成你的 Docker Hub 用户名或任意标识
docker build -t <用户名>/nuxt-blog:v1.0 .

-t：为镜像打标签，格式为 仓库名:版本。
.：表示当前目录的 Dockerfile。

运行 Docker 容器

docker run -d \
  -p 3000:3000 \
  --name nuxt-blog-container \
  <用户名>/nuxt-blog:v1.0

-d：后台运行容器。
-p 3000:3000：映射宿主机 3000 端口到容器 3000 端口。
--name：指定容器名称，方便管理。

测试访问：打开浏览器，访问 http://<服务器IP>:3000，能正常看到 Nuxt 页面即部署成功。

（可选）推送镜像到 Docker Hub

推送：

`1`	`docker push <用户名>/nuxt-blog:v1.0`

之后其他人只需：

1
2

docker pull <用户名>/nuxt-blog:v1.0
docker run -d -p 3000:3000 <用户名>/nuxt-blog:v1.0

即可一键运行。

（可选）用 Nginx 反向代理统一入口

若你希望通过域名（如 blog.linsou.asia）访问，并隐藏端口，可在服务器上安装并配置 Nginx：

安装 Nginx：

1
2

sudo yum install -y nginx   # CentOS
# 或 sudo apt install -y nginx   # Ubuntu

新建配置 /etc/nginx/conf.d/nuxt-blog.conf：

server {
  listen 80;
  server_name blog.linsou.asia;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

校验并重载：

1
2

sudo nginx -t
sudo systemctl reload nginx

访问 http://blog.linsou.asia 即可直达 Nuxt 应用。

恭喜你！🎉 通过本教程，你已掌握从 Windows 传输项目、在 Linux 服务器上打包 Docker 镜像并部署 Nuxt 应用的全流程。

初步接触Nginx

Wed, 23 Apr 2025 12:25:57 +0800

初步接触 Nginx

什么是 Nginx？

Nginx（engine x） 是一个高性能的 HTTP 和反向代理服务器，同时也是一个 IMAP/POP3/SMTP 邮件代理服务器。

由 Igor Sysoev 编写，最初用于俄罗斯访问量最大的网站之一。如今，它广泛应用于各类网站的：

静态资源服务（如 HTML、CSS、JS、图片等）
反向代理（把请求转发到后端服务）
负载均衡（分发请求以提升性能与可用性）
HTTPS / SSL 支持
动态请求的缓存与压缩处理

为什么使用 Nginx？

Nginx 被广泛采用的原因包括：

🚀 高性能：可以支撑成千上万个并发连接
⚙️ 资源占用小：内存占用远低于 Apache
🔁 反向代理 + 负载均衡：非常适合部署在微服务架构中
🔒 支持 HTTPS / SSL
🔧 模块化配置：配置灵活，易于扩展

安装 Nginx

1. 安装依赖

yum install gcc gcc-c++
yum install -y pcre pcre-devel
yum install -y zlib zlib-devel
yum install -y openssl openssl-devel

2. 下载并解压 Nginx

cd /usr/local
wget http://nginx.org/download/nginx-1.22.1.tar.gz
tar -zxvf nginx-1.22.1.tar.gz
cd nginx-1.22.1

3. 编译安装

1
2
3

./configure --with-http_ssl_module  # 添加 SSL 模块支持
make                                 # 编译
make install                         # 安装

🚀 常用命令整理

在 /usr/local/nginx/sbin 目录下运行：

1
2
3

./nginx              # 启动 Nginx
./nginx -s reload    # 热重载配置
./nginx -s stop      # 停止 Nginx

检查是否启动成功

`1`	`ps -ef \| grep nginx`

输出示例：

1
2

root    706455   1    0 12:34 ?  nginx: master process ./nginx
nobody  706456   ...  0 12:34 ?  nginx: worker process

判断启动状态：

✔️ 正常：出现 master process 和 worker process
❌ 异常：只有 master 没有 worker，说明配置有误
⚠️ 多个进程：说明重复启动了，建议先执行 pkill nginx

配置与测试

📄 配置文件示例（`nginx.conf`）

路径：/usr/local/nginx/conf/nginx.conf

# 定义工作进程数量，通常设置为 CPU 核心数，这里示例用1
worker_processes  1;

events {
    # 每个工作进程允许的最大连接数（含客户端和服务器端连接）
    worker_connections  1024;
}

http {
    # 引入 MIME 类型映射文件，用来识别文件扩展名对应的内容类型
    include       mime.types;
    # 默认的 MIME 类型，文件类型未匹配时使用
    default_type  application/octet-stream;

    # 启用高效文件传输方式，减少系统调用次数
    sendfile        on;
    # 连接保持活动的超时时间（秒），超过此时间关闭连接
    keepalive_timeout  65;

    server {
        # 监听端口8080，HTTP服务默认端口是80，这里改为8080示例
        listen       8080;
        # 服务器名称，支持域名或IP，这里用localhost作为本机测试
        server_name  localhost;

        location / {
            # 网站根目录，Nginx 会从这里查找文件
            root   /usr/local/nginx/html/dist;
            # 默认首页文件，访问目录时默认加载的文件
            index  index.html index.htm;
        }

        # 定义错误页面，当出现500、502、503、504错误时，跳转到该页面
        error_page   500 502 503 504  /50x.html;
    }
}

测试是否成功

`1`	`curl http://<你的公网IP>:8080`

如果返回页面内容，说明 Nginx 成功响应
否则检查防火墙 / 端口是否开放

⚠️ 注意事项

监听端口为 8080（非默认 80），需特别注意防火墙设置
如果你使用的是 阿里云服务器，请在控制台：
- 找到安全组 → 编辑入方向规则 → 开放 8080 端口

即使云服务器厂商（如阿里云、腾讯云等）的“安全组”已经开放端口，如果服务器操作系统内部还有防火墙规则没有放行对应端口，也会导致无法访问。

systemctl status firewalld

# 若正在运行，执行查看端口开放情况
firewall-cmd --list-all

# 若未开放指定端口，可执行
firewall-cmd --permanent --add-port=8080/tcp
firewall-cmd --reload

# 再次执行查看端口开放情况
firewall-cmd --list-all

##实操

[root@iZbp15al0g417943ohz4h1Z ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  services: cockpit dhcpv6-client ssh
  ports: 20/tcp 21/tcp 22/tcp 80/tcp 443/tcp 8888/tcp 39000-40000/tcp 9999/tcp 8080/tcp # 没有8989端口
  protocols: 
  forward: no
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
[root@iZbp15al0g417943ohz4h1Z ~]# firewall-cmd --permanent --add-port=8989/tcp
success
[root@iZbp15al0g417943ohz4h1Z ~]# firewall-cmd --reload
^[[Asuccess
[root@iZbp15al0g417943ohz4h1Z ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  services: cockpit dhcpv6-client ssh
  ports: 20/tcp 21/tcp 22/tcp 80/tcp 443/tcp 8888/tcp 39000-40000/tcp 9999/tcp 8080/tcp 8989/tcp
  protocols: 
  forward: no
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

若你更喜欢默认 HTTP 端口 80，可将 listen 8080 改为 listen 80

Nginx 配置 lindablog.xyz 域名启用 HTTPS

一、准备条件

部署项目文件位置：/usr/local/nginx/html/dist
阿里云申请 SSL 凭证档案（我申请的是免费证书3月一换）：
- jnalindablog.xyz.pem（凭证）
- jnalindablog.xyz.key（私钥）

二、建立 SSL 凭证目录并上传ssl凭证档案

`1`	`mkdir -p /usr/local/nginx/ssl`

三、撰写 Nginx HTTPS 配置档

在 /usr/local/nginx/conf/nginx.conf 中加入：

worker_processes 1;

events {
    worker_connections 1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout 65;

    # 加入這一行：引用你自定義的 server 配置檔案
    include /usr/local/nginx/conf/conf.d/*.conf;
}

在 /usr/local/nginx/conf/conf.d/lindablog.conf 中加入：

server {
    # 监听 443 端口并启用 SSL/TLS，提供 HTTPS 服务
    listen 443 ssl;
    # 服务器域名，配置成你的网站域名
    server_name lindablog.xyz;

    # SSL 证书文件路径，公钥证书
    ssl_certificate     /usr/local/nginx/ssl/jnalindablog.xyz.pem;
    # SSL 私钥文件路径，和证书匹配的私钥
    ssl_certificate_key /usr/local/nginx/ssl/jnalindablog.xyz.key;

    # 允许使用的 TLS 协议版本，推荐启用 1.2 和 1.3
    ssl_protocols TLSv1.2 TLSv1.3;
    # 加密套件，排除掉弱加密算法，确保连接安全
    ssl_ciphers HIGH:!aNULL:!MD5;

    # 网站根目录，存放前端静态文件
    root /usr/local/nginx/html/dist;
    # 默认首页文件，访问根路径时默认加载
    index index.html;

    location / {
        # try_files 尝试访问请求的 URI，如果不存在，则返回 index.html
        # 主要用于 SPA（单页应用）支持路由刷新
        try_files $uri $uri/ /index.html;
    }
}

server {
    # 监听 HTTP 的 80 端口，用于重定向所有请求到 HTTPS
    listen 80;
    # 服务器域名
    server_name lindablog.xyz;

    # 所有访问 80 端口的请求，都重定向（301永久重定向）到对应的 HTTPS 地址
    return 301 https://$host$request_uri;
}

四、测试与重载 Nginx

1
2

/usr/local/nginx/sbin/nginx -t
/usr/local/nginx/sbin/nginx -s reload

五、验证 HTTPS 启用

浏览器访问 https://lindablog.xyz，网址列显示锁头符号 🔒
点击锁头查看凭证细节或者右键检查找到隐私与安全
使用线上工具检查：
- SSL Labs 测试
- SSL Shopper 检查

备注

.pem 与 .crt 可通用于 Nginx

Webpack初步接触

Fri, 21 Mar 2025 11:49:00 +0800

Webpack 初步接触

一、什么是 Webpack？

Webpack 是一个 静态模块打包工具，用于将多个模块、文件和资源进行打包，以便在浏览器中高效加载和运行。

核心功能：

模块打包
整合 JS、CSS、图片等资源，提升代码可维护性和复用性。
依赖管理
自动解析模块依赖关系，确保正确加载顺序，降低手动管理复杂度。
代码转换与优化
通过 Loaders 转换代码（如 ES6 → ES5），并优化输出体积。
开发支持
支持 HMR（热更新）、Source Maps 调试、代码分割等，提升开发效率。
生态系统
丰富的插件（Plugins）和加载器（Loaders）扩展功能。

二、Webpack 构建流程

构建过程是串行的，主要分为以下阶段：

初始化参数
合并配置文件与命令行参数，生成最终配置。
启动编译
初始化 Compiler 对象，加载插件并调用 run 方法。
确定入口
根据 entry 配置定位所有入口文件。
编译模块
递归处理模块依赖：
- 调用 Loaders 转换文件内容（如编译 Sass → CSS）
- 解析模块依赖关系，直至所有模块处理完成。
输出资源
将模块组合为 Chunk，生成最终文件（如 JS/CSS 文件）。
写入文件系统
根据 output 配置输出文件到指定路径。

插件机制

Webpack 在构建生命周期广播事件（如 compile、emit），插件通过监听事件调用 API 修改输出结果。

三、常见 Loaders

Loader	功能描述
`raw-loader`	导入文件原始内容（如文本文件）。
`file-loader`	将文件输出到指定目录，返回 URL 路径。
`url-loader`	小于阈值的文件转为 Base64，否则调用 `file-loader`。
`babel-loader`	转换 ES6+ 代码为向后兼容的 JavaScript。
`ts-loader`	编译 TypeScript 为 JavaScript。
`sass-loader`	编译 Sass/SCSS 为 CSS。
`css-loader`	解析 CSS 文件中的 `@import` 和 `url()`。
`style-loader`	将 CSS 注入到 DOM 的 `<style>` 标签中。
`eslint-loader`	静态检查 JavaScript 代码规范。
`vue-loader`	处理 Vue 单文件组件（`.vue`）。

四、常见 Plugins

Plugin	功能描述
`DefinePlugin`	定义全局常量（如环境变量）。
`HtmlWebpackPlugin`	自动生成 HTML 文件并注入资源。
`MiniCssExtractPlugin`	将 CSS 提取为独立文件。
`UglifyJsPlugin`	压缩 JavaScript 代码。
`CleanWebpackPlugin`	构建前清理输出目录。
`WebpackBundleAnalyzer`	可视化分析打包体积。
`SpeedMeasurePlugin`	统计各 Loader/Plugin 的构建耗时。

五、Loader 与 Plugin 的区别

特性	Loader	Plugin
核心功能	转换特定类型文件（如编译 Sass）。	扩展 Webpack 功能（如代码压缩、资源注入）。
使用场景	处理单个文件的转换逻辑。	监听构建事件，执行全局操作。
配置方式	在 `module.rules` 中定义，按文件类型匹配。	在 `plugins` 数组中实例化，可传入参数。
实现原理	基于函数链式调用处理文件内容。	基于 Tapable 事件流，在生命周期钩子中干预构建。

什么是SEO？

Sat, 15 Mar 2025 13:29:13 +0800

SEO本质

解决两个匹配问题：

内容匹配：让网站内容精准对应搜索者的真实需求（比如用户搜「如何修复冰箱不制冷」，你的网页必须提供具体解决方案，而非只介绍冰箱品牌）
技术匹配：让搜索引擎能快速理解并推荐你的内容（比如用HTML标签明确标注文章主题、确保手机端加载速度低于2秒）

优化SEO的底层逻辑

不优化的结果	优化后的效果	对应技术手段
用户搜不到你（关键词缺失）	目标关键词进入前3页	关键词研究工具（如Google Keyword Planner）
搜索引擎误判内容（技术缺陷）	爬虫高效抓取内容	优化robots.txt文件、XML网站地图
用户点开就离开（体验差）	停留时间提升50%+	内容分段落+配图、添加目录导航
被算法判定为低质内容	获得「优质内容」权重加分	增加专业参考文献、作者资质说明
外链数量为0	获得行业权威网站推荐	制作可被引用的研究报告/工具

必须优化SEO的数学证明

设某关键词月搜索量1000次：

第1名点击率 ≈ 35% → 350次访问/月
第6名点击率 ≈ 4.5% → 45次访问/月
排名提升5位，流量增长678%

流量价值计算（假设转化率2%，客单价$100）：

第1名月收益：350×2%×$100 = $700
第6名月收益：45×2%×$100 = $90
SEO带来的边际收益差：$610/月

现代SEO的三个死亡红线

关键词堆砌（密度>2%即可能被惩罚）
忽视用户实际停留时间（Google已用屏幕停留时长替代跳出率作为核心指标）
忽略结构化数据（没有Schema标记的网页，点击率平均低37%）

SEO优化手段---Canonical

Fri, 14 Mar 2025 13:29:13 +0800

<link rel="canonical" href="xxxx/t">

主要目的：解决 重复内容（Duplicate Content） 问题，并明确告知搜索引擎哪个是页面的“规范版本”（Canonical URL）。

1. 什么是Canonical标签？

作用：当同一内容（页面）可通过多个不同URL访问时（例如带参数的URL、分页、移动端/PC端不同URL等），搜索引擎可能认为这些是重复内容，导致权重分散。通过 rel="canonical" 标签，可以指定一个 规范URL，告诉搜索引擎“这个URL是主要版本，请优先收录和排名”。

语法：

`1`	`<link rel="canonical" href="https://example.com/规范URL" />`

2. 为什么需要添加Canonical标签？

场景举例

URL参数导致的重复内容
- 例如：
  https://example.com/product?id=1（排序参数）
  https://example.com/product?id=1&sort=price
- 搜索引擎可能认为这是两个不同页面，但实际内容相同。通过设置规范URL为 https://example.com/product?id=1，可集中权重。
分页内容
- 例如：
  https://example.com/blog?page=1
  https://example.com/blog?page=2
- 可以在分页页面中设置规范URL指向主页面（如 https://example.com/blog），或为每个分页指定各自的规范URL。
移动端与桌面端不同URL
- 例如：
  https://m.example.com/page（移动端）
  https://www.example.com/page（桌面端）
- 可以在移动端页面添加规范标签指向桌面端URL，或反之（根据SEO策略决定）。

3. 如何正确使用Canonical标签？

规范URL必须是可访问的：确保 href 中的URL是真实存在的、200状态码的页面。
绝对URL优先：建议使用完整URL（如 https://example.com/t），而非相对路径（/t）。
避免链轮问题：多个页面不能互相指向对方作为规范URL（例如A→B，B→A），会导致搜索引擎无法识别。
分页处理：
- 如果分页内容独立，每个分页应指定自己的规范URL。
- 如果希望集中权重到主页面，所有分页的规范URL指向主页面。

4. 与301重定向的区别

301重定向：将用户和搜索引擎永久跳转到新URL，旧URL不再存在。 适用场景：页面迁移、URL结构变更。
Canonical标签：仅提示搜索引擎规范URL，用户仍可访问原URL。 适用场景：内容相同或高度相似的多个URL需要共存（如参数化URL）。

5. 常见错误

指向非规范域名：例如将 https://example.com/t 的规范URL设为 https://otherdomain.com/t，可能导致权重流失。
忽略动态参数：若规范URL带参数，需确保参数不影响内容（如 ?utm_source=... 可保留，但排序参数需排除）。
在非HTML页面使用：如PDF、图片等非HTML文件中添加无效。

6. 验证是否生效

使用 Google Search Console 的“URL检查”工具，查看Google是否识别了规范URL。
通过浏览器开发者工具查看页面源代码，确认标签正确添加。
点击Ctrl+U

7. Nuxt3举例实现方法

优化前

// 步骤1:获取本地地址或.env路径(可用其他方法实现)
const requestURL = useRequestURL().href??''

// 动态设置 SEO Meta 标签
useHead({
  title: fit[0].seo_setting.title??"", // 标题
  meta: [
    { name: 'description', content: fit[0].seo_setting.desc??"" }, // 描述
    { name: 'keywords', content: fit[0].seo_setting.keyword??'' }, // 关键词
    // 社交媒体优化（OpenGraph）
    { property: 'og:title', content: fit[0].seo_setting.title??'' },
    { property: 'og:description', content: fit[0].seo_setting.desc??'' }
  ],
  link:[
    {rel:'canonical',href:requestURL}
  ]
});

潜在问题

useRequestURL().href的使用风险：

在 SSR（服务器端渲染）时可能无法正确获取完整 URL（例如在静态导出或反向代理场景下）。如果 href 为空字符串，生成的 canonical 标签会变成 <link rel="canonical" href="">，这会被搜索引擎视为无效或错误的规范 URL，导致 SEO 权重流失

动态数据为空的兜底逻辑

fit[0].seo_setting.title??"" 依赖外部数据（如 API 响应），如果 fit 数组为空或字段缺失，会导致 title、description 等关键标签为空字符串，搜索引擎会认为页面信息不完整，影响排名。

代码健壮性改进建议

确保 fit[0].seo_setting 存在且字段完整，避免渲染时崩溃.

优化后

// 获取本地地址
const requestURL = process.server 
  ? useRequestURL().href // SSR 环境：直接获取完整 URL
  : window.location.href; // 客户端：使用浏览器 URL

// 动态设置 SEO Meta 标签
useHead({
  title: fit[0].seo_setting.title??"默认标题", // 标题
  meta: [
    { name: 'description', content: fit[0].seo_setting.desc??"默认描述" }, // 描述
    { name: 'keywords', content: fit[0].seo_setting.keyword??'默认关键词' }, // 关键词
    // 社交媒体优化（OpenGraph）
    { property: 'og:title', content: fit[0].seo_setting.title??'默认描述' },
    { property: 'og:description', content: fit[0].seo_setting.desc??'默认描述' }
  ],
  link:[
    {rel:'canonical',href:requestURL}
  ]
});

代码整体对 SEO 的价值

核心作用：

通过动态设置元标签和规范链接，解决、关键词匹配、权重集中、跨平台展示三大 SEO 核心问题。
直接收益：

提升搜索排名（通过标题/描述优化）、减少重复内容惩罚（通过 canonical)、增强社交传播效果（通过 OpenGraph社交媒体优化）。

gitee仓库的第一次推送遇见的错误

Wed, 20 Nov 2024 00:00:00 +0000

推送失败，gitee仓库缺少公钥

`1`	`git push origin lsk_dev`

The authenticity of host 'gitee.com (180.76.198.77)' can't be established.
ED25519 key fingerprint is SHA256:+ULzij2u99B9eWYFTw1Q4ErYG/aepHLbu96PAUCoV88.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? y
Please type 'yes', 'no' or the fingerprint: yes
Warning: Permanently added 'gitee.com' (ED25519) to the list of known hosts.
git@gitee.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

检查与自己gitee仓库连接失败，没有显示hellow

`1`	`ssh -T git@gitee.com`

`1`	`git@gitee.com: Permission denied (publickey).`

进行公钥配置

`1`	`ssh-keygen -t rsa -C "14062626+linsk27@user.noreply.gitee.com"`

Generating public/private rsa key pair.
Enter file in which to save the key (C:\Users\lsk69/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\lsk69/.ssh/id_rsa
Your public key has been saved in C:\Users\lsk69/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:SOV+Ur+E321Pw+9NL77mSgZm6V8lc+W3LJi3rN5qXG8 14062626+linsk27@user.noreply.gitee.com
The key's randomart image is:
+---[RSA 3072]----+
|        .        |
|       o         |
|      . . .     .|
|     . o . +   ..|
|      . S B o o =|
|         * +o+o*o|
|          oo*o+==|
|           *+.=E*|
|          o+=O=+*|
+----[SHA256]-----+

获取公钥失败

`1`	`ssh-agent -s`

unable to start ssh-agent service, error :1058

> Fix Error **unable to start ssh-agent service, error: 1058(xxxx)**
>
> 1. win + R, Go To `services.msc`
>
> 2. Find And Check Is `OpenSSH Authentication Agent` Service Running
>

再次运行公钥获取成功，连接成功

1
2
3

ssh-agent -s

ssh -T git@gitee.com

`1`	`Hi linsk27(@linsk27)! You've successfully authenticated, but GITEE.COM does not provide shell access.`

复制公钥数据到gitee仓库的公钥（设置）

把ssh密钥添加到码云

打开C盘–>用户–>你的用户名–>找到.ssh文件夹。找到id_rsa.pub（日过有多个用最新的那个），用记事本打开，复制整个文本粘贴到gitee（点头像，进入gitee设置面板，SSH设置，将复制的文本粘贴到公钥，标题会自动生成，然后点击添加，根据提示输入密码就可以了。）

重新推送成功

`1`	`git push origin lsk_dev`

Enumerating objects: 16, done.
Counting objects: 100% (16/16), done.
Delta compression using up to 16 threads
Compressing objects: 100% (15/15), done.
Writing objects: 100% (16/16), 2.19 KiB | 2.19 MiB/s, done.
Total 16 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Powered by GITEE.COM [1.1.5]
remote: Set trace flag 824c4db5
remote: Create a pull request for 'lsk_dev' on Gitee by visiting:
remote: https://gitee.com/larrry/competition-system/pull/new/larrry:lsk_dev...larrry:main
To gitee.com:larrry/competition-system.git
 * [new branch]      lsk_dev -> lsk_dev

工程 on 404_@林达

DigitalPlat 免费域名配置教程：从领取到 Cloudflare 解析

准备工作

第一步：在 DigitalPlat 里检查域名

第二步：先去 Cloudflare 添加站点

第三步：回 DigitalPlat 填写 nameserver

第四步：等待 Cloudflare 检测生效

第五步：在 Cloudflare 添加 DNS 解析

第六步：配置 SSL/TLS

常见问题

1. DigitalPlat 注册时报 403

2. Cloudflare 一直显示等待 nameserver

3. 域名注册成功但打不开网站

4. 是否需要开启 WHOIS Privacy

总结

ProofPR PR 证据检查器

适合谁

项目价值

技术方向

项目入口

AI Vue Flask Blog 全栈系统

适合谁

项目价值

技术方向

项目入口

初步接触Docker

Docker 笔记：常用命令整理

镜像管理

容器管理

docker-compose 常用

常用组合示例

清理空间

我的fre123部署流程

🐳 Nuxt 博客项目从 Windows 上传到阿里云服务器并用 Docker 部署上线教程

前置条件

将项目上传到阿里云服务器

方法一：FinalShell 右键上传

方法二：命令行 scp

在服务器上编写 Dockerfile

构建 Docker 镜像

运行 Docker 容器

（可选）推送镜像到 Docker Hub

（可选）用 Nginx 反向代理统一入口

初步接触Nginx

初步接触 Nginx

什么是 Nginx？

为什么使用 Nginx？

安装 Nginx

1. 安装依赖

2. 下载并解压 Nginx

3. 编译安装

🚀 常用命令整理

检查是否启动成功

配置与测试

📄 配置文件示例（nginx.conf）

测试是否成功

⚠️ 注意事项

Nginx 配置 lindablog.xyz 域名启用 HTTPS

一、准备条件

二、建立 SSL 凭证目录并上传ssl凭证档案

三、撰写 Nginx HTTPS 配置档

四、测试与重载 Nginx

五、验证 HTTPS 启用

备注

Webpack初步接触

Webpack 初步接触

一、什么是 Webpack？

核心功能：

二、Webpack 构建流程

插件机制

三、常见 Loaders

四、常见 Plugins

五、Loader 与 Plugin 的区别

什么是SEO？

SEO本质

优化SEO的底层逻辑

必须优化SEO的数学证明

现代SEO的三个死亡红线

SEO优化手段---Canonical

1. 什么是Canonical标签？

方法二：命令行 `scp`

📄 配置文件示例（`nginx.conf`）