openclaw plugins install @tencent-connect/openclaw-qqbot@latest

这个脚本，会出现下面这个提示

npm install failed:

npm 安装依赖失败，尝试了很多次都会提示这个(之前运行这个脚本就没遇到这个情况，很玄学) 。

经过了一天的折腾，找到了问题所在和解决方案

问题核心原因

1. OpenClaw 内置安装机制的「过度限制」

OpenClaw 的 plugins install 命令不是简单调用 npm install，而是加了多层校验：

• 检测插件代码中的 child_process（Shell 执行）、环境变量读取等行为，即使是插件正常功能，也会触发「安全拦截」；
• 内置的 npm 执行环境被限制了权限 / 超时时间，一旦依赖下载稍慢或编译耗时，就会直接判定「npm install failed」；
• 临时目录（/tmp/openclaw-plugin-*）的权限 / 生命周期管控严格，手动操作稍慢就会被自动清理。

2. 服务器基础环境不匹配

• Node.js 版本：插件要求 node >=24，openclaw安装脚本安装的默认版本是 v22.22.1，部分依赖编译会出现问题；
• 编译依赖缺失：插件中的音频转换、系统调用类依赖需要 gcc/g++/python，即使安装了基础编译环境，低版本系统仍可能编译失败；
• 资源不足：服务器内存 / CPU 不足时，npm install 会因资源抢占卡住，表现为「无报错但一直卡」。

3. 网络层的隐性问题

• npm 源的「安全审计接口」在国内镜像（如淘宝源）未实现，触发 404 警告，OpenClaw 会误判为安装失败；
• 依赖包分片下载时，服务器网络波动导致超时，npm 无重试机制，直接终止安装；
• 部分依赖包（如二进制预编译包）的 CDN 节点在境外，下载速度极慢甚至超时。

分步解决方案

1.升级node版本

# 全局安装 n 工具
npm install -g n

# 如果提示权限不足（Permission denied），加 sudo 执行
sudo npm install -g n

# 安装并切换到 v24 最新稳定版
sudo n 24

# 查看 Node.js 版本（输出 v24.x.x 即为成功）
node -v

# 查看 npm 版本（同步升级，无需单独操作）
npm -v

2.将npm源改成官方源

国内镜像会出现更新不同步的问题

npm config set registry https://registry.npmjs.org/

3.直接通过npm安装插件

绕过OpenClaw 插件安装机制的限制

npm install -g @tencent-connect/openclaw-qqbot@latest

等待安装好之后把 npm 安装好的包迁移到 OpenClaw 插件目录

4.定位插件安装路径

# 1. 自动定位 npm 全局安装的插件路径（兼容不同系统）
PLUGIN_PATH=$(npm root -g)/@tencent-connect/openclaw-qqbot

# 2. 验证路径是否存在（不存在则提示错误）
if [ ! -d "$PLUGIN_PATH" ]; then
  echo "❌ 插件安装失败，请检查 npm install 命令是否执行成功"
  exit 1
else
  echo "✅ 插件安装路径：$PLUGIN_PATH"
fi

5.迁移到 OpenClaw 插件目录

# 1. 删除 OpenClaw 旧的未完成目录
rm -rf /root/.openclaw/extensions/openclaw-qqbot

# 2. 将 npm 安装好的插件完整复制过去
cp -r $PLUGIN_PATH /root/.openclaw/extensions/openclaw-qqbot

# 3. 赋予正确权限
chown -R $USER:$USER /root/.openclaw/extensions/openclaw-qqbot
chmod -R 755 /root/.openclaw/extensions/openclaw-qqbot

6.配置信任 & 验证插件

# 1. 配置 plugins.allow 消除安全提示
cat > /root/.openclaw/config.json << EOF
{
  "plugins": {
    "allow": ["@tencent-connect/openclaw-qqbot", "wecom-app"]
  }
}
EOF

# 2.重启OpenClaw服务
openclaw gateway restart

# 2. 最终验证（看到插件名称即为成功）
openclaw plugins list | grep openclaw-qqbot

7.配置 QQ 机器人

# 1.配置绑定当前QQ机器人
openclaw channels add --channel qqbot --token "190xxxxx:iT9xxxxxx"

# 2.重启OpenClaw服务
openclaw gateway restart

总结

1. 核心解决思路：绕过 OpenClaw 内置安装机制，手动用 npm 安装插件后迁移到指定目录；
2. 关键前置：升级 Node.js 到 v24+、安装编译依赖、切换 npm 官方源，解决底层环境问题；
3. 验证要点：插件迁移后需配置信任列表，重启服务并通过 openclaw plugins list 确认加载成功。

2008 年，一位化名中本聪的神秘人物（或组织）发表了比特币白皮书，提出一种去中心化的数字货币构想，旨在实现无需传统金融机构的交易体系。次年，即 2009 年，中本聪基于白皮书中的理念，开发出比特币钱包软件，并公开供用户下载使用，比特币网络由此正式启动。

二、比特币网络搭建

当新用户下载并运行比特币钱包软件时，软件会自动连接内置的种子节点。这些种子节点如同网络的 “联络站”，会向新用户节点分享其已连接的其他节点信息。新用户节点借此与众多对等节点建立起 P2P（点对点）连接。在这个过程中，各个节点按照既定规则相互交换信息，逐渐构建起一个没有中心控制的比特币网络。网络中的所有节点地位平等，共同维护着网络的正常运转。这种 P2P 网络结构确保了比特币系统的去中心化特性，没有任何一个节点能够单独掌控整个网络。

三、钱包地址生成

每个用户都可以通过本地的比特币钱包软件生成独一无二的钱包地址。钱包地址类似于现实生活中的银行账号，是用户在比特币网络中接收和存储比特币的标识。它由钱包软件依据特定算法生成，整个生成过程无需依赖第三方机构，极大地保障了用户的自主性和隐私性。这意味着用户可以完全掌控自己的钱包地址，无需担心第三方机构的干预或泄露风险。

四、内存池功能

钱包软件会在用户电脑里开辟一块默认大小为 300M 的内存空间，这就是内存池。它就像一个 “交易等待区”，主要任务是临时存放转账记录。当用户发起交易时，相关的转账信息会先被暂存到内存池中，等待被打包进区块，成为区块链账本的一部分。内存池中的交易处于待确认状态，它们在这里排队等待被矿工打包处理。

五、创世区块诞生

1. 铸币交易：比特币网络的首个钱包用户开始创建区块 0 。在这个过程中，该用户通过一种特殊的 coinbase 铸币交易，凭空给自己的钱包地址转入 50 枚比特币。这 50 枚比特币是比特币网络给予打包区块者的初始奖励，此后每四年奖励减半。这种奖励机制旨在激励更多节点参与到比特币网络的维护和新区块的创建中来，为比特币网络的发展提供动力。
2. 提取记录：完成铸币交易后，由于此时网络刚刚起步，内存池中仅有这笔铸币交易，并无其他交易，用户便从内存池中提取该转账记录，随后进入打包区块头环节。

六、打包区块头流程

1. 确定交易记录：将从内存池提取的铸币交易记录确定为该区块要记录的交易内容，这是构成区块的核心数据。

2. 交易哈希运算：对确定好的铸币交易进行哈希运算。哈希算法具有三个重要特性：

   • 唯一性：无论何时何地，对相同的数据进行哈希运算，得到的结果始终固定且唯一。例如，无论谁对字符 “a” 进行 SHA256 哈希运算，都会得到相同的哈希值。这保证了每个交易在经过哈希运算后都有独一无二的标识。
   • 不可逆性：无法通过哈希值反向推导出原始数据内容。比如将一篇文章进行哈希运算后，他人无法从哈希值还原出文章原文。这为交易信息提供了保密性。
   • 雪崩效应：原始数据哪怕只有极其微小的改动，都会导致哈希运算结果截然不同。通过对交易记录进行哈希运算得到的数值，会被填入区块头。这使得任何对交易的篡改都会导致哈希值的明显变化，从而易于被发现。

1. 添加相关信息：

   • 上一区块哈希值：因为这是首个区块，不存在上一个区块，所以在区块头此位置填 0 。后续区块则会在此处填入上一区块的哈希值，通过这种方式将各个区块依次连接起来，形成区块链结构。这种链式结构保证了区块链数据的连贯性和可追溯性，每个区块都依赖于前一个区块的哈希值，一旦前面的区块被篡改，后续区块的哈希值就会不匹配。
   • 时间戳：记录区块创建的时间，为区块链提供时间维度信息，用于确定交易顺序和区块先后关系，帮助节点验证数据的真实性和顺序性。时间戳使得区块链上的交易和区块按照时间顺序排列，便于追踪和验证。
   • 规定难度：区块头设定当前难度值，如 0X1D00FFFF ，该值决定挖矿难度。难度值会根据全网算力的变化而动态调整，以确保比特币网络平均每 10 分钟产生一个新区块。难度值的调整是比特币网络自我调节的重要机制，保证了出块速度的稳定性。
   • 随机数：初始值设为 0 ，在挖矿过程中，通过不断改变随机数重新计算哈希值，以寻找符合难度要求的结果。随机数是挖矿过程中不断尝试的变量，通过调整它来改变哈希运算结果，是挖矿找到有效区块的关键因素之一。

七、挖矿过程解析

1. 哈希计算与比较：对打包好的区块头进行哈希计算，会得到一个很大的数值。该数值需与当前设定的难度值（bits）进行比较。若计算值小于 bits ，则挖矿成功；若大于 bits ，需改变随机数重新计算哈希值，反复尝试直至找到小于 bits 的数值。这个过程就像是在海量数字中碰运气，每秒计算哈希值的次数越多（即算力越高），挖到矿的概率就越大。可以想象成在一个巨大的数字迷宫中寻找特定的出口，算力就是寻找出口的速度。
2. 难度调整与时间控制：比特币网络设定大约每 10 分钟产生一个区块。为实现这一目标，会根据全网算力的变化动态调整难度值。每挖出 2016 个区块（大约两周时间），系统会检查挖矿平均速度。若平均出块时间快于 10 分钟，表明全网算力提升，将增加挖矿难度（减小 bits 值）；若慢于 10 分钟，说明全网算力降低，将降低挖矿难度（增大 bits 值）。通过这种自动调整机制，确保比特币网络维持相对稳定的出块节奏，使得比特币的发行和交易能够有序进行。
3. 新区块传播与验证：当某节点成功挖到矿，会立即向其邻居节点发送新区块哈希值。邻居节点发现自身无此区块，便向该节点索要完整区块数据。收到后，邻居节点对区块头进行哈希计算，验证哈希值与接收到的一致且小于 bits 规定难度，确认区块有效后，将其保存至自身电脑的区块链数据库，并继续向其他节点传播。首个挖出的区块即创世区块，创世区块诞生后，比特币网络随即开启第二个区块的挖掘。新区块的传播和验证过程确保了整个比特币网络数据的一致性和准确性。

八、后续区块挖掘与交易处理

1. 第二个区块挖掘：第二个区块挖掘流程与首个类似。节点先创建铸币交易，奖励自己 50 枚比特币，接着从内存池提取交易记录（此时内存池可能已有其他交易，如转账交易）放入区块。随后打包区块头，填入所有交易哈希值及上一区块（创世区块）的哈希值，添加时间戳、目标难度、随机数等信息，通过改变随机数计算哈希值，竞争挖掘新区块。不同节点同时竞争，谁先找到符合难度要求的哈希值，谁就成功挖到第二个区块。在这个过程中，各个节点都在努力尝试找到合适的随机数，以满足难度要求，就像一场紧张的竞赛。
2. 交易处理：例如，某用户（假设为 A）要向另一用户（假设为 B）转账比特币。A 先确认自己拥有足够且未花费的比特币，如在创世区块获得的 50 枚。A 创建交易，给 B 转 9 枚比特币，同时给自己转回剩余比特币（假设转回 40 枚，遵循比特币需花完之前交易金额的规则），剩余 1 枚作为矿工手续费。A 将交易信息广播给邻居节点，其他节点验证 A 是否有足够比特币。通过查之前区块确认后，接受交易并暂存于内存池。此时 B 的钱包显示收到 9 枚比特币，但处于未确认状态。当某节点成功挖到包含该交易的新区块并广播，其他节点验证有效后加入区块链数据库，同时从内存池删除该交易，B 才真正收到比特币。随着新区块不断生成，区块链不断增长，交易记录被永久记录，确保交易不可篡改与可追溯。这个过程保证了比特币交易的安全性和可靠性，每一笔交易都被准确记录在区块链上。

九、挖矿意义

挖矿在比特币网络中起着核心作用。由于每个节点都能构建区块，为确定使用哪个区块添加到区块链，设计了挖矿机制。挖矿基于 PoW（工作量证明），是一种竞争性记账机制。只有率先找到符合条件哈希值（小于规定难度值）的节点，其构建的区块才能被添加到区块链，并获得挖矿奖励。每个区块头包含上一区块哈希值，形成链式结构。若有人篡改某区块内容，该区块哈希值改变，后续区块哈希值对应不上，链会断开。比特币网络只认可最长区块链，篡改无效。理论上，若个体或组织拥有超全网 51% 的算力，可从创世区块重新挖矿改写历史，即 “51% 算力攻击”。但现实中，要超越比特币全网目前 900EH/s 的算力几乎不可能，保障了比特币网络的安全与稳定。挖矿不仅是产生新比特币的方式，更是维护比特币网络安全和一致性的重要手段。

前端开发中，有一个高频踩坑场景：前端绑定域名后，HTTP 协议下请求后端 IP 接口一切正常，可一旦开启 SSL 切换为 HTTPS，接口就直接请求失败，控制台报出红色错误 —— 这不是代码 Bug，而是浏览器的安全限制，核心原因就是「Mixed Content（混合内容）」。

一、先明确核心概念：Mixed Content（混合内容）

首先厘清两个基础认知，避免混淆：

1. HTTPS 的本质

   HTTPS = HTTP + TLS（Transport Layer Security，传输层安全协议），相当于给 HTTP 传输的数据加了一层加密外套，防止数据被窃听、篡改，保障访问安全；而 HTTP 是明文传输，无任何加密保护。我们常说的「开启 SSL」，本质就是启用 HTTPS 加密。

2. Mixed Content（混合内容）的定义

   当 HTTPS 加密页面 中，请求了 HTTP 明文资源 时，就属于 Mixed Content（混合内容）。

   浏览器的安全逻辑：HTTPS 页面代表用户处于安全的加密环境，若此时请求 HTTP 明文接口，传输的数据会暴露在风险中，可能被抓包、篡改。因此，浏览器会强制拦截此类请求，这是无法通过后端配置绕过的硬规则。

浏览器控制台的标准报错：

Mixed Content: The page at 'https://yourdomain.com' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://your-server-ip:port/api'. This request has been blocked; the content must be served over HTTPS.

二、重点解答：HTTPS 页面能否请求 HTTP 接口？

结论：对于接口请求（fetch/axios/XHR），现代浏览器 100% 拦截，无生产可用的例外场景。

浏览器将 Mixed Content 分为两类，仅被动内容有极特殊情况：

• 被动内容（Passive Mixed Content）：如图片、CSS、字体，部分浏览器可能放行，但会标红警告，无实际生产意义；
• 主动内容（Active Mixed Content）：如接口请求、JS 脚本、XHR/fetch，所有现代浏览器（Chrome/Edge/Firefox 等）一律强制拦截，这也是我们踩坑的核心场景。

补充：手动关闭浏览器混合内容拦截（仅测试用），无法推广给普通用户，生产环境完全不可用。

三、最简单、一劳永逸的解决方案（Nginx 代理）

核心思路：让前端和接口「同域名、同 HTTPS」，彻底规避 Mixed Content 和跨域，无需修改后端代码。

最终实现效果

前端：https://yourdomain.com （HTTPS 加密，原域名）；

接口：https://yourdomain.com/api （同域名、同 HTTPS，通过 Nginx 代理到后端）。

Nginx 核心配置（复制即用，替换实际信息）

server {

listen 443 ssl;

server_name [yourdomain.com](https://yourdomain.com);  # 你的前端域名

# SSL 证书配置（复用前端证书，无需额外申请）

ssl_certificate /your-ssl-path/yourdomain.pem;

ssl_certificate_key /your-ssl-path/yourdomain.key;
    
# 前端静态资源配置（无需部署前端可删除）

location / {

root /your-frontend-path;

index index.html;

}
    
#核心：接口代理，转发 /api 请求到后端 HTTP 服务
    
location /api {

proxy_pass http://your-server-ip:your-server-port;  # 后端 IP + 端口

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

}

}

# 可选：80 端口自动跳转 HTTPS，优化用户体验

server {

listen 80;

server_name [yourdomain.com](https://yourdomain.com);

return 301 https://hostrequest_uri;

}

前端代码修改（1 行搞定）

原写法（硬编码 HTTP 协议和 IP 地址，触发 Mixed Content 拦截）：

fetch('http://your-server-ip:your-server-port/api/xxx')

修改后（使用相对路径，自动继承页面的 HTTPS 协议和域名，规避混合内容）：

fetch('/api/xxx')

四、终极避坑口诀（记牢不踩坑）

1. HTTPS 页面只能请求 HTTPS 接口，否则触发 Mixed Content 拦截；
2. HTTP 页面可请求 HTTP/HTTPS 接口，无 Mixed Content 限制；
3. 跨域可通过后端 CORS 解决，Mixed Content 只能统一 HTTPS 协议；
4. 接口类主动内容，HTTPS 页面请求 HTTP 接口必失败，无例外。

背景知识

从2022年底ChatGPT的一鸣惊人，再到持续进行的”百模大战”，”大模型”已经逐渐成为了技术和公众领域的热点。

大模型是人工智能领域的一个重要里程碑，它推动了人工智能技术的发展，并为人类的未来带来新的可能性。有人曾经类比，大模型的发明相当于人类文明的哪个节点？一个浪漫的答案可能是：人类学会使用火的时刻。

人工智能

定义：人工智能（AI）是一门使机器模拟人类智能过程的学科，其中具体包括学习、推理、自我修正、感知和处理语言等功能。人工智能涉及计算机科学、数据分析、统计学、机器工程、语言学、神经科学、哲学和心理学等多个学科的领域，旨在研究、设计、构建具备智能、学习、推理和行动能力的计算机和机器。

分类

• 机器学习(ML)：研究计算机如何在没有明确编程的情况下，通过对数据的分析、学习，自动改进其行为或做出预测的学科。旨在使计算机系统具备从经验中学习的能力，以适应新情况、结局问题或完成特定任务。

  根据工作模式分类：

  • 监督学习：学习为人提供的数据，对具备某种特征的数据进行人为标记。
  • 无监督学习：根据数据特征进行相似归类。
  • 强化学习：奖励机制，猜对了奖励，猜错了不给奖励。

• 深度学习(DL)：是机器学习的一个分支，主要使用神经网络模型对数据进行学习和表示。深度学习算法试图模拟人类大脑的工作方式，通过对大量数据的学习，自动提取出数据的高层次特征和模式，从而实现图像识别、语音识别、自然语言处理等任务。

  神经网络的分类：

  • 卷积神经网络 CNNs
  • 循环神经网络 RNNs
  • Transformer网络

• 生成式人工智能(GenerativeAI)：深度学习中快速增长的子集，使用大模型提供支持，在大量原始、未标记的数据基础上对深度学习模型进行预训练，使得机器能够“理解”语言甚至图像，并能够根据需要自动生成内容。

大模型

提出：2021年，斯坦福大学的研究员团队发表了一篇论文，提出了Foundational Models（基础模型，即大模型）的概念。

定义：它是一类具有大量参数（通常在十亿以上），能在极为广泛的数据上进行训练，并适用于多种任务和应用的预训练深度学习模型。

大模型的训练的三个阶段

• 预训练(Pre-training)：在这个阶段大模型会从海量的互联网文本中学习，掌握语言的统计规律、事实性知识以及上下文关联能力。但它本质上只是学会了“预测下一个词”或“补全句子”，并没有真正理解人类提问的意图。它虽然“知道很多”，却还不懂得“如何回应人的请求”。因此，我们需要通过监督微调（SFT）来教会它遵循指令。

• 监督微调(SFT)：在这个阶段大模型会学习大量由人类精心构造的“指令-回答”样本，涵盖日常对话、逻辑推理、专业问答等多种场景。通过这些示范，模型学会将用户的输入理解为明确的指令，并给出有针对性的回应。经过SFT，模型已经具备了基本的指令遵循能力和任务完成能力。但它仍可能输出不恰当的内容——比如包含偏见、虚假信息、不安全言论等，因为它只学会了“怎么答”，还没学会“什么该答、什么不该答”。

• 对齐偏好(Preference Alignment)：在这个阶段大模型会针对同一个问题生成多个不同的回答，由人类评估者根据有用性、安全性、礼貌性、事实准确性等标准进行比较和选择。模型通过学习这些“人类更喜欢哪个回答”的信号，逐渐调整自己的输出方式，使得回答不仅正确，而且更符合人类的价值观和交流习惯。

  实现对齐的方式：

  • 基于人类反馈的强化学习（RLHF，Reinforcement Learning from Human Feedback），先用人类标注的数据训练一个“评分老师”（奖励模型），再让这个“老师”指导大模型改进回答。
  • DPO（Direct Preference Optimization），跳过训练“老师”的中间步骤，直接根据人类偏好数据优化模型本身。这个方法简化了训练流程，效果也很好

大模型的特点

• 规模和参数量大
• 适应性和灵活性强
• 广泛数据集的预训练
• 计算资源需求大

大模型分类

• 大语言模型(LLM)：这类大模型专注于自然语言处理（NLP），旨在处理语言、文章、对话等自然语言文本。它们通常基于深度学习架构（如Transformer模型），经过大规模文本数据集训练而成，能够捕捉语言的复杂性，包括语法、语义、语境以及蕴含的文化和社会知识。语言大模型典型应用包括文本生成、问答系统、文本分类、机器翻译、对话系统等。

• 多模态模型：多模态大模型能够同时处理和理解来自不同感知通道（如文本、图像、音频、视频等）的数据，并在这些模态之间建立关联和交互。它们能够整合不同类型的输入信息，进行跨模态推理、生成和理解任务。多模态大模型的应用涵盖视觉问答、图像描述生成、跨模态检索、多媒体内容理解等领域。

  模态组合：

  • 视觉+文本：包括VQA视觉问答，图像字幕，图文检索、文生图等应用。
  • 音频+文本：包括语音生成、语音摘要、语音识别等应用。
  • 音频+视觉：包括音生图、演讲人脸生成等应用。

大模型工作原理

用户在可以使用自然语言与大模型交流，用户的文本就是“提示词”。提示词越清晰，模型的回答就越符合预期。

大模型处理提示词的工作流程可以分为两部分，第一部分是分词化与词表映射，第二部分为生成文本。

分词化

分词化（Tokenization）是自然语言处理（NLP）中的重要概念，它是将段落和句子分割成更小的分词（token）的过程。

分词化的粒度分类：

• 词粒度（Word-Level Tokenization）分词化，适用于大多数西方语言，如英语。
• 字符粒度（Character-Level）分词化，是中文最直接的分词方法，以单个汉字为单位进行分词化。
• 子词粒度（Subword-Level）分词化，它将单词分解成更小的单位，比如词根、词缀等。这种方法对于处理新词（比如专有名词、网络用语等）特别有效，因为即使是新词，它的组成部分（子词）很可能已经存在于词表中了。

词表映射

分出的词就是token，每一个token都会通过预先设置好的词表，映射为一个 token id，这是token 的“身份证”，一句话最终会被表示为一个元素为token id的列表，供计算机进行下一步处理。

生成文本

大语言模型的工作概括来说是根据给定的文本预测下一个token。对我们来说，看似像在对大模型提问，但实际上是给了大模型一串提示文本，让它可以对后续的文本进行推理。

大模型的推理过程不是一步到位的，当大模型进行推理时，它会基于现有的token，根据概率最大原则预测出下一个最有可能的token，然后将该预测的token加入到输入序列中，并将更新后的输入序列继续输入大模型预测下一个token，这个过程叫做自回归。直到输出特殊token（如，end of sentence，专门用来控制推理何时结束）或输出长度达到阈值。

大模型的经典应用场景

• 文本生成
• 文本编辑
• 推理分析
• 总结概要

提示词

提示词（Prompt）是用户发送给大语言模型的问题、指令或请求，来明确地告诉模型用户想要解决的问题或完成的任务，是大语言模型理解用户需求并据此生成相关、准确回答或内容的基础。对于大语言模型来说，提示词就是用户输入给大语言模型的文本信息。

提示词Prompt—->大语言模型LLM—->返回结果Completion

提示词工程

提示词工程（Prompt Engineering）就是研究如何构建和调整提示词，从而让大语言模型实现各种符合用户预期的任务的过程。

提示词工程包括以下关键步骤：

1. 理解任务需求
2. 构建有效提示词
3. 评估提示词效果
4. 持续迭代改进

提示词技巧

直接提问

直接提问，也称为零样本提示（Zero-Shot Prompting），即不给大语言模型提供案例，完全依靠 LLM 理解和处理能力完成任务。适用于目标明确、问题简单、答案确定且唯一等场景。

直接提问时，可遵循以下原则：

• 简洁：尽量用最简短的方式表达问题。过于冗长的问题可能包含多余的信息，导致模型理解错误或答非所问。
• 具体：避免抽象的问题，确保问题是具体的，不含糊。
• 详细上下文：如果问题涉及特定上下文或背景信息，要提供足够的详情以帮助模型理解，即使是直接提问也不例外。
• 避免歧义：如果一个词或短语可能有多重含义，要么明确其含义，要么重新表述以消除歧义。
• 逻辑清晰：问题应逻辑连贯，避免出现逻辑上的混淆或矛盾，这样才能促使模型提供有意义的回答。

增加示例

在提示词中提供少量（通常几个或几十个）示例，也称为少样本提示（Few-Shot Prompting），以帮助模型更好地理解任务要求和期望输出。比如：

• 让 LLM 跟随我们所要求的规范、格式、概念、文法、语气进行输出。
• 提供进一步推理的参考，比如让大模型学会数学运算或按照示例方式进行逻辑推理。

增加示例时可参考以下技巧：

• 精选代表性样本：选择具有代表性的示例，覆盖任务的各种情况，同时避免使用可能引起模型混淆的极端或边缘案例，确保模型能从有限的数据中学习到任务的核心特征。
• 保证示例的多样性：尽可能覆盖任务的各种角度和情境，确保模型能从有限的数据中学习到任务的核心特征。
• 使用相似的格式和结构：在所有示例中使用相似的提示格式和结构，使模型能够清晰识别输入与输出的关系。
• 让大语言模型生成示例：实践时，我们还可以先让 LLM 按照提示生成一些示例，再进行筛选或人工调整，以提高示例质量和针对性。

分配角色

赋予模型一个具体的角色或身份，来引导模型在特定角色视角下生成回答。

分配角色适用以下场景：

• 需要专业知识或特定视角的问题解答。例如，模拟老师、医生、律师等回答相关领域的问题。
• 模拟特定人物或角色的语言风格。例如，模仿某个著名人物（如历史人物或文学角色）语言风格的文本时。
• 进行角色扮演游戏或创作。在创意写作或角色扮演游戏中扮演指定的角色，与使用者进行互动。
• 在特定行业内进行决策模拟。例如，模拟一个管理咨询师来分析商业案例或提供商业建议。

分配角色引导模型生成符合特定情境和对话逻辑的内容，可遵循以下技巧：

• 明确角色身份与特性
  • 确定角色的基本属性，如年龄、性别、职业、性格、技能、价值观等。
  • 赋予角色相关领域的专业知识或特殊背景，如专家、学者、历史人物、虚构角色等。
• 设定角色目标与动机
  • 为角色设定对话的目标，如寻求信息、说服他人、解决问题、分享观点等。
  • 揭示角色的内在动机，如个人利益、道德信念、情感需求等，有助于塑造角色的真实性和深度。
• 设定角色语言风格：
  • 根据角色性格、教育水平、文化背景等设定其语言习惯、用词选择、句式结构、口头禅等。
  • 规定角色在对话中的情绪状态，如冷静理智、激动愤怒、悲伤失落、幽默风趣等，影响其表达方式。
• 设定角色规则约束：规定角色在对话中的行为约束，如不得人身攻击、保持礼貌尊重、遵守讨论主题等。
• 动态调整角色设定：
  • 随着对话深入，适时调整角色设定以适应新的情境和话题，如角色态度转变、关系演变、目标更新等。
  • 向模型反馈角色表现，如偏离设定、缺乏个性、对话僵化等，及时修正角色设定并引导模型调整。

限定输出风格/格式

为了更好的限定“风格”，准确引导模型写出符合需求的内容，下面我们介绍一些推荐的技巧：

1. 明确指出所需的内容类型，如“论文/散文/诗歌/新闻报道/剧本/日记”等。
2. 用形容词限定风格，如“严谨客观”、“感性抒情”、“幽默诙谐”、“庄重典雅”等。
3. 列举风格（代表人物/作品）示例，如“仿照鲁迅先生的笔触描述社会现象”或“以J.K.罗琳的叙述风格撰写一段奇幻冒险故事”。
4. 设定语境与情感色彩：为模型设定故事背景、情感基调或角色视角，影响其语言表达和修辞选择，从而形成特定风格。如“以一名二战老兵的视角，深情回忆战场经历”。
5. 规定语言与句式特点：要求使用特定词汇、短语、成语、俚语、古语等，或强调长句、短句、排比、反问、比喻等修辞手法的运用，以契合特定风格。

还可以进一步对内容的输出格式进行限定：

1. 明确输出长度：如“撰写一篇关于全球气候变化的新闻报道，标题需简洁明快，概括主题，不超过300字”。
2. 段落结构：规定正文的段落数量、每段的大致内容与逻辑关系，如“文章分为引言、主体（分三点论述）和结论三部分”。
3. 列表与编号：要求使用项目符号、数字编号等形式列出要点或步骤，如“通过数字编号列出五种有效的时间管理方法，并简要解释”。
4. 引用与注释：指示何时使用引号、脚注、尾注、参考文献等格式引用他人观点或资料，如“在论述中适当引用至少两篇相关学术论文，并按照APA格式添加引用和参考文献”。
5. 格式标记：如对齐方式（左对齐、居中、右对齐）、字体样式（加粗、斜体、下划线）、缩进、行距、页眉页脚等进行详细说明，甚至可以要求大模型按照JSON格式输出。
6. 特殊要求：针对特定场景，如邮件、信函、通知、海报、简历等，规定相应的格式标准，如“按照商务电子邮件的标准格式撰写邀请函，包括收件人、抄送人、主题、问候语、正文、结束语、签名档等部分”。

拆解复杂任务

把一个复杂的任务，拆解成多个稍微简单的任务，让大语言模型分步来思考问题，称为思维链（Chain-of-Thought Prompting, CoT）提示，这种方式可让大语言模型像人类一样逐步解释或进行推理，从而极大地提升 LLM 的能力。

思维链分类：

• 零样本思维链（Zero-shot CoT）：没有给 LLM 提供问题解析示例。

• 少样本思维链（Few-shot Cot）：给 LLM 提供问题解析示例。

  有时 LLM 通过零样本思维链可能会得到错误的答案，可以通过增加示例的方式，即少样本思维链，帮助 LLM 理解相关任务并正确执行。

提示词框架

提示词可以包含的要素：

• 指令 Instruction：需要模型去做什么，如回答某个问题、撰写某种类型的文章或按照特定格式进行总结。指令应该简洁、明确，确保 LLM 能够理解任务的目标和要求。

• 背景信息 Context：背景信息可以包括任务的背景、目的相关的各类信息，还可以为 LLM 设置角色背景、观点立场等信息，LLM 将在此背景下进行回应或生成文本。

• 参考样本 Examples：与解决用户问题相关的示例，比如通过少样本提示的方式帮助 LLM 更好理解如何处理指令。

• 输入数据 Input Data：用户输入指令和要求，比如用什么语气，生成多少字的内容。

• 输出指示 Output Indicator：指定输出的类型或格式，我们可以给出限定关键词、限制条件或要求的输出格式/方式（如表格），也可以避免无关或不期望的信息出现。

结合上述要素，我们可以根据任务的复杂度来设计提示词，具体有以下几种情况：

1. 纯指令型：最直接的互动方式，仅通过简明指令向模型提出需求，适合于寻求快速、基本答案的场景。
2. 背景+指令：在指令基础上融入背景信息，为模型创造一个理解和响应任务的框架，尤其适用于需要考虑特定情境或角色定位的任务。
3. 指令/背景+输出指示：在基础指令或背景信息之上，加入输出指示，精确指导模型如何组织和呈现答案，以满足特定的格式或风格要求。
4. 综合型提示：结合指令、背景信息、输入数据与输出指示，形成一个全方位的引导体系。这种复合型提示尤为强大，能够在复杂任务中提高模型输出的针对性与质量，尤其是在模型需要从示例中学习并模仿特定风格或结构时。

常见提示词框架及场景

推理模型

推理模型通常指专门优化用于逻辑推理、问题解决、多步推断等任务的模型，它们通常在数学解题、代码生成、逻辑分析等方面有更好的表现。与通用模型相比，推理模型拥有更强的逻辑能力，因为它经过了大量的专项训练，能够更好地理解复杂的问题，并且在解答时更有条理。但并不是说就一定比通用模型更好，两种模型都有各自的应用场景，下表从一些典型维度对这两类模型进行了对比：

推理模型还是通用模型？如何选择？以下是一些推荐：

• 明确的通用任务：对于明确定义的问题，通用模型一般能够很好地处理。
• 复杂任务：对于非常复杂的任务，且需要给出相对更精确和可靠的答案，推荐使用推理模型。这些任务可能有：
  • 模糊的任务：任务相关信息很少，你无法提供模型相对明确的指引。
  • 大海捞针：传递大量非结构化数据，提取最相关的信息或寻找关联/差别。
  • 调试和改进代码：需要审查并进一步调试、改进大量代码。
• 速度和成本：一般来说推理模型的推理时间较长，如果你对于时间和成本敏感，且任务复杂度不高，通用模型可能是更好的选择。

当然你还可以在你的应用中结合使用两种模型：使用推理模型完成Agent的规划和决策，使用通用模型完成任务执行。

推理模型在面对相对模糊的任务也能给出详尽且格式良好的响应。因此，使用一些提示词技巧（如指示模型“逐步思考”）可能反而限制了模型的推理。下面列举了一些适用于推理模型的提示技巧：

• 直接提问：保持提示简洁、清晰，且明确任务限制。
• 避免思维链提示：你无需提示推理模型“逐步思考”或“解释你的推理”，它们本身会进行深入的思考。
• 根据模型响应调整提示词：直接提问推理模型通常能够产生良好的响应，但如果你有更复杂精细的要求，可以在提示词中明确，比如有明确的输入信息和输出要求时，你可以通过增加示例明确这些信息，还可以通过分隔符帮助推理模型区分不同的信息模块。这个过程可以是重复多次的，不断尝试调整提示，让模型不断推理迭代，直到符合你的要求。

插件

定义：大模型插件是一种软件组件，它们设计用于增强和扩展基础大模型的功能。如网络搜索、视觉生成、语音合成等。

典型的插件包括：

• 基础工具，如计算器、时钟、天气信息、股票行情
• 可以让用户获得实时性消息的插件，比如体育赛事报道、实时、热点新闻
• 可以为模型拓展更多能力的插件，比如图片生成、语音合成、代码解释器

工作原理

首先接收输入，判断是否需要使用工具及选择合适的工具，然后使用工具并获得返回结果进行后续推理生成。

用户提问-> 程序根据用户问题调用大模型->大模型判断是否需要调用工具->大模型输出工具名称解析工具入参->程序根据工具名称、入参调用工具->工具输出运行结果->程序根据工具结果、用户提问重新调用大模型->大模型给出回复->程序展示结果给用户

RAG

RAG（Retrieval-Augmented Generation，检索增强生成） 是一种结合了信息检索技术与语言生成模型的人工智能技术。该技术通过从外部知识库中检索相关信息，并将其作为提示（Prompt）输入给大型语言模型（LLMs），以增强模型处理知识密集型任务的能力，如问答、文本摘要、内容生成等。

• 内置知识库
• 用户定制知识库

实现原理

检索增强生成包括三个步骤，建立索引、检索、生成。

建立索引：首先要清洗和提取原始数据，将 PDF、Docx等不同格式的文件解析为纯文本数据；然后将文本数据分割成更小的片段（chunk）；最后将这些片段经过嵌入模型转换成向量数据（此过程叫做embedding），并将原始语料块和嵌入向量以键值对形式存储到向量数据库中，以便进行后续快速且频繁的搜索。这就是建立索引的过程。

检索生成：系统会获取到用户输入，随后计算出用户的问题与向量数据库中的文档块之间的相似度，选择相似度最高的K个文档块（K值可以自己设置）作为回答当前问题的知识。知识与问题会合并到提示词模板中提交给大模型，大模型给出回复。这就是检索生成的过程。

提示词模板类似于：请阅读：{知识文档块}，请问：{用户的问题}

RAG 存在的问题

• 问题比较抽象或者概念比较模糊，导致大模型没有准确理解使用者的问题。
• 知识库没有检索到问题的答案
• 缺少对答案做兜底验证的机制

RAG评测标准

• 考察检索模块的准确性，如准确率、召回率、F1值等等；
• 考察生成模块生成答案的价值，如相关性、真实性等等。

参考Ragas提及的评测矩阵指南，可以建立一些自己的评测指标。

改造方案

提升索引准确度

• 优化文本解析过程，正确的从文档中提取有效语料。

• 优化chunk切分模式

  • 利用领域专有知识进行精准切分
  • 基于固定大小切分
  • 上下文感知，切分时考虑前后文关系避免信息断裂

• 句子滑动窗口检索，通过设置window_size（窗口大小）来调整提取句子的数量，当用户的问题匹配到一个chunk语料块时，通过窗函数提取目标语料块的上下文，而不仅仅是语料块本身，这样来获得更完整的语料上下文信息，提升RAG生成质量。

• 自动合并检索，将文档分块，建成一棵语料块的树，比如1024切分、512切分、128切分，并构造出一棵文档结构树。当应用作搜索时，如果同一个父节点的多个叶子节点被选中，则返回整个父节点对应的语料块。

• 选择更适合业务的Embedding模型

  把chunk语料块由原来的文本内容转换为机器可以用于比对计算的一组数字，即变为Embedding向量。

• 选择更合适业务的ReRank模型，好的ReRank模型会让更贴近用户问题的chunks的排名更靠前。

• Raptor用聚类为文档块建立索引，这就像通过文档的内容为文档自动建立目录的过程。

让问题更好理解

• Enrich完善用户问题

  • 多轮对话补全需求

  • 大模型转述用户问题

  • 让用户补全信息

• Multi-Query 多路召回，先一次性改写出多种用户问题，让大模型根据用户提出的问题，从多种不同角度去生成有一定提问角度或提问内容上存在差异的问题。让这些存在差异的问题作为大模型对用户真实需求的猜测，然后再把每个问题分别生成答案，并总结出最终答案。

  提示词模板

  You are an AI language model assistant. Your task is to generate five different versions of the given user question to retrieve relevant documents from a vector database. By generating multiple perspectives on the user question, your goal is to help the user overcome some of the limitations of the distance-based similarity search. Provide these alternative questions separated by newlines. Original question: {question}

• RAG-Fusion过滤融合，在经过多路召回获取了各种语料块之后，并不是将所有检索到的语料块都交给大模型，而是先进行一轮筛选，给检索到的语料块进行去重操作，然后按照与原问题的相关性进行排序，再将语料块打包喂给大模型来生成答案。

• Step Back 问题摘要，让大模型先对问题进行一轮抽象，从大体上去把握用户的问题，获得一层高级思考下的语料块。

• Decomposition问题分解，用户的问题拆成一个一个小问题来理解，或者可以说是RAG中的CoT。

  提示词

  You are a helpful assistant that generates multiple sub-questions related to an input question. \n The goal is to break down the input into a set of sub-problems / sub-questions that can be answers in isolation. \n Generate multiple search queries related to: {question} \n Output (3 queries):

  • 串行执行
  • 并行执行

• HyDE假设答案，让大模型先来根据用户的问题生成一段假设答案，然后用这段假设的答案作为新的问题去文档库里匹配新的文档块，再进行总结，生成最终答案。

  用户提问->生成答案->信息抽离->生成答案

改造信息抽取途径

Corrective Retrieval Augmented Generation (CRAG)是一种改善提取信息质量的策略：如果通过知识库检索得到的信息与用户问题相关性太低，我们就主动搜索互联网，将网络搜索到的信息与知识库搜索到的信息合并，再让大模型进行整理给出最终答案。

两种实现方式

• 向量相似度，我们用检索信息得到的向量相似度分来判断。判断每个语料块与用户问题的相似度评分，是否高过某个阈值，如果搜索到的语料块与用户问题的相似度都比较低，就代表知识库中的信息与用户问题不太相关；

• 直接问大模型，我们可以先将知识库检索到的信息交给大模型，让大模型自主判断，这些资料是否能回答用户的问题。

回答前反复思考

Self-RAG，也称为self-reflection，是一种通过在应用中设计反馈路径实现自我反思的策略。
基于这个思想，我们可以让应用问自己三个问题：

• 相关性：我获取的这些材料和问题相关吗？ 在生成答案前判断，不相关就改写问题。

• 无幻觉：我的答案是不是按照材料写的来讲，还是我自己编造的？在生成答案后判断，出现幻觉就重新生成答案。

• 已解答：我的答案是不是解答了问题？在输出答案前判断，没有解答问题就改写问题。

从多个数据源中获取资料

• 从数据库中获取统计指标，大模型可以将用户问题转化为SQL语句去数据库中检索相关信息，这个能力就是NL2SQL（Natural Language to SQL）。
• 从知识图谱中获取数据，Neo4j是一款图数据库引擎，可以为我们提供知识图谱构建和计算服务。在知识图谱上，我们调用各种图分析算法，如标签传播、关键节点发现等等，可以快速检索多度关联关系，挖掘隐藏关系。

微调

核心思想：在预训练的基础上，使用特定领域的数据对模型进行进一步的训练，从而让模型更擅长处理你想要解决的问题，也就是说，让大模型更懂你。

微调的特点

1. 数据规模小
2. 训练时间短

微调可以实现

• 风格化，角色扮演
• 格式化，系统对接

微调的作用

提高效率降低成本

微调的关键

• 需要特定领域的高质量数据
• 需要配置合适的参数才能达到想要的微调效果

微调的使用场景

如果你的部署环境里无法提供知识检索服务，或者你单纯希望大模型记住这些重要的信息。你可以考虑使用微调，为大模型注入专有领域的知识库，确保大模型的回答会更准确、更高效。

业务决策

• 业务需求匹配度

  首先明确业务的具体需求，明确要通过大模型微调解决的具体业务问题和应用场景。可以先问自己以下问题：

  • 你的任务是否需要复杂的语言理解或生成能力？例如，复杂的自然语言生成、意图识别等任务可能受益于大模型微调。
  • 你的任务是否需要高度特定于某个领域或任务的语言能力？例如，法律文书分析、医学文本理解等领域任务。
  • 当前的模型是否已能满足大部分需求？如果能满足，则可能不需要微调。
  • 是否有具体的业务指标来衡量微调前后效果对比？比如微调后的大模型推送给客户的信息更加准确，从而降低投诉率。

• 数据可用性与质量

  微调需要足够的高质量领域特定数据。需要评估当前业务系统中是否能够提取出足够的标注数据用于训练，以及数据的质量、代表性是否满足要求。

• 合规与隐私

  业务工作者需要确保使用的数据符合法律法规要求，处理个人数据时遵循隐私保护原则，尤其是GDPR等国际和地区隐私法规。此外，还要关注模型偏见、过拟合、泛化能力不足等潜在风险，以及这些风险对业务可能造成的影响。

• 资源和技术可行性

  微调过程需要计算资源和时间成本，包括GPU资源、存储空间以及可能的专家人力成本。需要评估项目预算和资源是否允许进行有效微调。

  团队是否具备微调大模型所需的技术能力和经验，或者是否有合适的合作伙伴提供技术支持。

微调流程

1. 准备数据
   • 数据收集：收集用于微调模型的数据，例如之前的交互记录、常见问题及回答等。
   • 数据清洗：清洗这些数据，去除敏感信息，保证数据的质量。
2. 模型选择
   • 选择适合的预训练大模型。准备一个或多个有使用权限的通用大模型。
3. 模型微调
   • 使用你收集的数据来微调所选模型。
   • 标注数据：如果需要，对数据进行标注以支持监督学习。
   • 微调模型：运行微调程序，调整模型的参数使其更适应你的业务数据。
4. 模型评估
   • 你可以在准备训练集的同时，准备一份与训练集格式一致的评测集，该评测集用来评测微调后模型的效果。如果评测集数据条目较少，你可以直接去观察微调后模型的输出，并与评测集的output进行比较。
5. 模型集成
   • 编写代码将模型调用集成到现有的业务流程中去。
   • 设定合理的调用逻辑和流程，如何处理模型的输出，如何处理API调用错误等。
   • 确保API调用遵守数据保护法规。
   • 实施适当的身份验证和授权控制。
6. 测试与优化
   • 在开发和测试环境中测试API调用和模型集成。
   • 根据测试结果优化模型性能。
7. 模型部署
   • 在生产环境中部署微调后的模型。
8. 监控与维护
   • 监控模型的性能和API的健康状况。
   • 定期重新评估和优化模型以适应新数据和业务变化。
9. 持续迭代
   • 根据用户反馈和业务需求的变化，继续改进模型和API。

在进行这一切工作时，保持良好的文档习惯也至关重要，这样团队成员可以轻松跟踪项目的进展，新加入的成员也能够快速上手。此外，确保所有与微调和部署模型相关的关键决策都得到适当记录和备份。

微调的方式

大模型由多个子模块组成

全参微调（Full Fine Tuning）是在预训练模型的基础上进行全量参数微调的模型优化方法，只要有参数，就会被调整。该方法避免消耗重新开始训练模型所有参数所需的大量计算资源，又能避免部分参数未被微调导致模型性能下降。但是，大模型训练成本高昂，需要庞大的计算资源和大量的数据，即使是全参数微调，往往也需要较高的训练成本。

高效微调 PEFT（Parameter-Efficient Fine-Tuning）旨在降低微调参数的数量和计算复杂度的同时提高预训练模型在新任务上的性能，缓解微调大型预训练模型的训练成本，只需要调整某几层网络的参数即可。当前比较主流的 PEFT 方法包括 Adapter Tuning、Prompt Tuning、LoRA 等等。

• LoRA 的全称是 “Low-Rank Adaptation”（低秩适应）。它不对原模型做微调，而是在原始模型旁边增加一个旁路，通过学习小参数的低秩矩阵来近似模型权重矩阵的参数更新，训练时只优化低秩矩阵参数，通过降维度再升维度的操作来大量压缩需要训练的参数。
• Adapter Tuning，该方法会在原有的模型架构上，在某些位置之间插入Adapter层，微调训练时只训练这些Adapter层，而原先的参数不会参与训练。该方法可以在只额外增加3.6%参数的情况下达到与全参数微调相似的效果。
• Prefix Tuning，该方法不改变原有模型的结构，而是给文本数据的token之前构造一段固定长度任务相关的虚拟token作为前缀Prefix。训练的时候只更新这个虚拟token部分的参数，而其他部分参数固定。这些前缀向量可以视为对模型进行引导的“指令”，帮助模型理解即将处理的任务。由于只需学习远少于模型全部参数数量的前缀向量，这种方法极大地减少了内存占用和计算成本。
• Prompt Tuning，一种轻量高效的微调方法，其原理与Prefix Tuning类似，但仅在输入层加入可训练的prompt tokens向量（而非像Prefix Tuning那样作用于每层Transformer）来引导模型输出。这些提示词向量并不一定放在问题的前边，也可以针对不同的任务设计不同的提示词向量。微调训练只对这些前缀提示词向量进行更新，从而不修改大模型本身的参数，大幅减少训练参数。

RAG v.s. 微调

Agent

定义：从软件工程的角度来看，大模型Agent是指基于大语言模型的，能使用工具与外部世界进行交互的计算机程序。

Agent的工作流程

1. 感知
2. 思考
3. 行动

Agent的能力

• 记忆能力

  • 短期记忆，对应着用户与大模型Agent之间的历史对话、提示词、搜索工具反馈的语料块等等，但这些信息仅与当前用户与大模型的对话内容有关。一旦用户关闭应用或离开聊天环境，这类信息就消失了。
  • 长期记忆，对应着系统持久化的信息，如业务历史记录、知识库等，通常存储在外部向量数据库和文档库中，Agent会利用长期记忆来回答用户私有知识或专业领域相关的问题。

• 规划能力

  • 任务分解

    • 思维链
    • 思维树
    • 思维图

  • 推理与反思，让大模型先审视自己的结果，然后再输出结果。

    • ReAct，现原理是把思考、推理、观察整合到提示词模版中，让大模型在具体工作中既可以基于环境反馈选择使用何种工具来完成工作，又可以基于环境反馈推理是否可以给出任务的答案。

      大模型在ReAct提示词的引导下完成推理、行动、再推理、再行动，直至生成最终答案。

      • 当大模型接收到用户请求的时候，大模型先判断能不能解答用户的问题。
      • 当大模型不能解答用户的问题时，大模型会根据可用工具列表的介绍，选择一个合适的工具。
      • 大模型根据工具的使用说明生成调用指令，并在指令中插入需要的参数。
      • Agent主体程序会根据大模型生成的指令来调用对应的工具服务
      • Agent主体程序等待工具执行完成并收集执行结果。
      • 带着用户问题和执行结果，大模型会再次考虑是否已经解决了问题。如果没有解决，就继续选择一个工具来执行。如果解决了，大模型会生成最终答案，并结束任务。

      提示词模板

      input_variables=['agent_scratchpad', 'input', 'tool_names', 'tools'] template='Answer the following questions as best you can. You have access to the following tools: {tools} Use the following format: Question: the input question you must answer Thought: you should always think about what to do Action: the action to take, should be one of [{tool_names}] Action Input: the input to the action Observation: the result of the action ... (this Thought/Action/Action Input/Observation can repeat N times) Thought: I now know the final answer Final Answer: the final answer to the original input question Begin! Question: {input} Thought:{agent_scratchpad}'

Agent与大模型的区别

1. 它不局限于输出回答，还能通过插件（工具）与外部世界交互，论上只要是计算机程序能做的事情，它都能做到。
2. 它不再是被动式地接受多轮提问，而是能自主地推理（拆解任务、选择最优路径）、主动纠错、自主完成任务。你可以让它每完成一个或多个步骤就给你同步进展，和你确认下一步的动作，也可以授权它自主地完成所有步骤。
3. 它不仅可以完成简单的事情，还能完成复杂的任务。
4. 它可以自我迭代，吸取历史经验，不断成长，因为它不仅能记住这次会话里你对它的指导，还能记住以前的会话里你给它提过的要求。
5. 它不仅能完成通用的任务，还能完成特定领域的任务，因为它可以接入特定领域的外部知识库和工具。

Multi-Agent

通过给每个Agent制定明确且专业的角色名称和职责描述，不仅可以提升它们的专业性，还能帮助它们更好地理解和配合各自的工作。

Agent之间可以互相指派任务，也可以是一个主Agent带着一系列从Agent协同工作。

多模态大模型

每一种信息的来源或者形式，都可以称为一种模态（Modality）。

在大模型领域，模态指的是数据或信息的类型或表达形式，文本、图像、视频、音频等都是不同的模态。多模态，顾名思义，就是指结合两种及以上的模态，进行更综合的数据处理和分析。

混合专家模型（MoE）

混合专家模型的核心思想就是术有专攻，类似“专家会诊”，由多个不同领域的模型（即“专家”）组合成一个模型，分别去解决不同领域的问题。

• Experts（专家网络）：每个专家网络是用来处理某一特定类型问题或数据子集的独立模型，一般都在他们各自的专长上受过训练，推理时只有部分专家网络参与计算。
• GateNet（门控网络）：类似于“交通指挥官”，负责评估输入数据，并决定由哪些专家参与处理当前的问题，尽可能地利用每个专家的专业知识来提供最准确的预测或决策输出。

局限性：

• 计算资源需求高：MoE模型中的每个专家都是一个独立的模型，当专家数量增加时，模型的总参数量也相应增加，导致部署模型可能需要更多的GPU显存资源。
• 过拟合风险：由于参数量大和复杂性，可能比简单模型更容易过拟合训练数据，特别是当数据量不足时。

大小模型云端协同

将大模型部署在云端，向边、端的小模型输出模型能力，小模型负责实时数据处理和初步推理，并向大模型反馈算法与执行成效，这样既能在云端充分发挥大模型的推理训练能力，又能调动边、端的小模型的敏捷性，可实现合理分配计算资源、提高响应速度。

Agent与多模态

• Agent概念通常指的是可以通过组件或工具与外界环境进行交互的大模型应用。它能够扩展模型的功能，比如增加特定领域的知识、优化交互流程或实现定制化逻辑，使模型更加灵活高效地应用于实际场景。
• 多模态指的是模型能够处理和整合多种类型的数据，如文本、图像、声音等。在大模型领域，多模态技术的融合旨在让模型具备跨媒体理解和生成能力，这对于提升模型在复杂应用场景中的表现至关重要，如图文并茂的问答系统、视频内容分析等。

一、相关工具（含使用场景）

• 在线检测NAT类型：NAT Checker（核心功能：检测映射/过滤行为，精准判定NAT1-9类型，建议打洞前必测）
• 通用打洞工具：Tailscale（适配EasyNAT全场景，HardNAT需依赖UPnP，操作简单，适合新手）
• 复杂NAT适配工具：Easytier（支持端口扫描/预测，可尝试HardNAT组合，适合进阶用户）
• 辅助排查工具：Wireshark（抓包分析流量走向，定位打洞失败原因，如端口过滤、映射端口变化）

二、必备知识（打洞原理基础）

路由器通过两张核心表实现NAT管控，这是打洞能否成功的关键：

1. NAT映射表：记录内部主机（内网IP:端口）与公网（公网IP:端口）的映射关系，仅当内部主机向外发起请求时生成/更新；
2. 状态表：记录内部主机的对外请求状态（如请求目标IP:端口、连接状态），仅当外部流量与状态表匹配时，才允许穿透NAT进入内网。

打洞的核心逻辑：通过中转服务器交换双方公网映射信息，再主动发起请求触发对方状态表更新，让后续流量能被放行。

2.1 NAT映射行为（决定公网端口是否固定）

• 地址和端口相关映射（HardNAT特征）：仅当请求的「目标IP+目标端口」与历史请求完全一致时，才复用原公网映射端口；只要有一项不同，就生成新的公网端口（如内网主机先访问中转服务器A:8080，再访问主机B:80，会生成两个不同公网端口）。
• 地址相关映射（HardNAT特征）：只要请求的「目标IP」与历史一致，即使目标端口不同，也复用原公网端口；若目标IP不同，则生成新端口（如内网主机访问A:8080和A:80，共用一个公网端口；访问A:8080和B:80，生成两个端口）。
• 端点无关映射（EasyNAT特征）：无论请求的目标IP、目标端口如何变化，始终复用同一个公网映射端口（如内网主机访问A:8080、B:80、C:443，均使用同一个公网端口）。

2.2 NAT过滤行为（决定外部流量能否放行）

• 地址和端口相关过滤：仅当外部响应的「源IP+源端口」与内部主机之前的请求目标完全一致时，才放行流量；否则直接过滤。
• 地址相关过滤：只要外部响应的「源IP」与内部请求的目标IP一致，即使源端口不同，也放行流量；源IP不同则过滤。
• 端点无关过滤：无论外部响应的源IP、源端口是什么，均直接放行（最宽松的过滤规则）。

2.3 NAT类型对照表（含打洞难度标注）

三、各NAT类型打洞可行性（详细拆解）

前置操作：双方均通过NAT Checker确认自身NAT类型，安装Tailscale（基础场景）或Easytier（复杂场景），确保双方网络能访问中转服务器（Tailscale/Easytier官方服务器）。

3.1 NAT1（全锥型） ↔ NAT1（全锥型）

核心原理

双方均为端点无关映射（公网端口固定）+ 端点无关过滤（任意外部流量放行），无需触发状态表更新，交换公网信息后可直接通信。

实战步骤

1. 双方启动Tailscale，自动连接中转服务器，完成身份认证；
2. 中转服务器同步双方的公网IP和映射端口（因端点无关映射，此端口固定不变）；
3. 双方获取对方公网信息后，直接向对方的「公网IP:映射端口」发起TCP/UDP连接；
4. 由于双方过滤规则宽松，流量直接放行，打洞成功，后续通信脱离中转服务器。

可行性结论

✅ 100%稳定可行，无特殊条件限制，是打洞最理想的场景。

问题排查

若失败，优先排查：① 防火墙是否拦截对应端口（如Tailscale默认使用41641端口，需放行）；② 公网IP是否为运营商内网IP（极少数情况，可通过IP138查询公网IP是否一致）。

3.2 NAT1（全锥型） ↔ NAT3（端口受限锥型）

核心原理

NAT1公网端口固定+过滤宽松，NAT3公网端口固定但过滤严格（仅放行「之前请求过的IP+端口」的响应）。关键是让NAT3先向NAT1发起请求，更新NAT3的状态表，从而放行NAT1的后续请求。

实战步骤

1. 双方启动Tailscale，连接中转服务器，同步对方公网IP:端口（记为NAT1：A:PortA；NAT3：B:PortB）；
2. 关键操作：让NAT3主机主动向NAT1的A:PortA发起请求（Tailscale会自动触发此步骤，无需手动操作）；
3. NAT3的状态表更新：记录「请求目标A:PortA」，此时允许A:PortA的流量进入内网；
4. NAT1主机向NAT3的B:PortB发起请求，由于NAT3状态表已记录A:PortA，此请求被放行；
5. 双方建立双向连接，打洞成功。

可行性结论

✅ 可行性95%以上，核心依赖「NAT3先发起请求」的顺序，Tailscale等工具会自动协调此顺序，无需手动干预。

问题排查

若失败，排查：① NAT3主机是否被路由器限制“主动对外发起连接”；② 双方是否同时启动工具（若NAT1先发起请求，会被NAT3过滤，可重启双方Tailscale重试）。

3.3 NAT3（端口受限锥型） ↔ NAT3（端口受限锥型）

核心原理

双方均为“端口固定+地址和端口相关过滤”，仅放行「自身之前请求过的IP:端口」的流量。需让双方在极短时间内同时向对方发起请求，互相更新对方的状态表，实现流量双向放行。

实战步骤

1. 双方启动Tailscale，连接中转服务器，同步对方公网IP:端口（NAT3-1：C:PortC；NAT3-2：D:PortD）；
2. 工具协调：Tailscale会通过中转服务器向双方发送“同步发起请求”的指令，确保双方在1秒内同时行动；
3. 双方同时向对方公网地址发起请求：NAT3-1→D:PortD；NAT3-2→C:PortC；
4. 双方状态表同时更新：NAT3-1记录D:PortD，允许其流量进入；NAT3-2记录C:PortC，允许其流量进入；
5. 双方请求均被对方放行，建立双向连接，打洞成功。

可行性结论

✅ 可行性90%以上，核心依赖「双方同时发起请求」的时间同步。若网络延迟过高（如跨运营商、跨地域），同步难度增加，成功率会略降。

问题排查

若失败，排查：① 双方网络延迟是否过高（可通过ping中转服务器判断，延迟>200ms建议换同运营商网络）；② 工具是否未正常协调同步请求（重启工具或切换网络重试）。

3.4 NAT1（全锥型） ↔ NAT4（地址相关映射+端点无关过滤）

核心原理

NAT1公网端口固定，NAT4为HardNAT（映射端口随目标IP变化）：NAT4向中转服务器发起请求时，生成映射端口Port4-1；当NAT4向NAT1发起请求时，因目标IP变化，会生成新的映射端口Port4-2（与Port4-1不同）。打洞关键是让NAT1识别到NAT4的新端口Port4-2，重新发起请求。

实战步骤

1. 双方启动Tailscale，连接中转服务器，同步的NAT4公网信息为「E:Port4-1」（NAT4与中转服务器通信的端口）；
2. NAT1先向E:Port4-1发起请求，因Port4-1仅对应“NAT4→中转服务器”的状态，此请求被NAT4的映射表匹配失败，直接过滤；
3. 中转服务器触发NAT4向NAT1的A:PortA发起请求，此时NAT4因目标IP变为A，生成新映射端口Port4-2；
4. NAT1接收到NAT4的请求（源地址E:Port4-2），自动更新NAT4的公网信息为「E:Port4-2」；
5. NAT1向E:Port4-2重新发起请求，此时NAT4的状态表已记录「请求目标A:PortA」，且Port4-2为当前映射端口，请求被放行；
6. 双方建立连接，打洞成功。

可行性结论

⚠️ 可行性70%左右，需依赖工具支持“动态端口识别与二次请求”（Tailscale、Easytier均支持）。若NAT4的映射端口变化频繁（如部分运营商每30秒刷新一次），可能导致连接不稳定。

问题排查

若失败，排查：① 工具是否支持动态端口更新（老旧版本可能不支持，需升级）；② NAT4的映射端口刷新周期是否过短（可通过Wireshark抓包观察端口变化频率）。

3.5 NAT3（端口受限锥型） ↔ NAT4（地址相关映射+端点无关过滤）

核心原理

双方均有严格限制：NAT3仅放行「自身请求过的IP:端口」，NAT4映射端口随目标IP变化。常规情况下，NAT3请求NAT4的“中转端口”会被过滤，NAT4请求NAT3时，因NAT3未记录其新端口，也会被过滤。需通过辅助方案突破限制。

实战步骤（分两种辅助方案）

方案1：开启UPnP/NAT-PNP（推荐，成功率高）

1. 登录NAT4所在的路由器管理后台，找到「UPnP」或「NAT-PNP」功能（通常在“高级设置-端口映射”中），开启该功能；
2. 双方启动Tailscale，工具会通过UPnP向路由器申请“固定映射端口”（强制NAT4使用固定端口，而非动态变化）；
3. 后续步骤与「NAT3↔NAT3」一致：双方通过中转服务器同步固定端口，同时发起请求，互相更新状态表；
4. 流量双向放行，打洞成功。

方案2：使用Easytier（无UPnP时备选，成功率低）

1. 双方启动Easytier，工具自动检测到NAT类型组合，触发“端口扫描+预测”模式；
2. NAT4主机向NAT3的C:PortC连续发送100-500条请求（目标端口固定，源端口动态生成，形成多个映射端口：Port4-3、Port4-4…）；
3. NAT3主机同时向NAT4的E:Port4-3~Port4-500依次发起扫描请求；
4. 当NAT3扫描到NAT4正在向自己发起请求的端口（如Port4-10）时，双方状态表同时记录对方信息，请求被放行，建立连接。

可行性结论

❌ 常规不可行；✅ 开启UPnP后可行性85%；⚠️ 用Easytier可行性30%-50%（依赖端口扫描命中率，且易被运营商判定为网络攻击，不推荐公网使用）。

问题排查

若UPnP方案失败，排查：① 路由器是否支持UPnP（部分老旧路由器无此功能）；② 工具是否有权限调用UPnP（需以管理员身份运行）；若Easytier方案失败，排查：① 网络是否限制高频端口扫描（如企业内网可能拦截）；② 双方网络延迟是否过高（延迟越高，扫描命中率越低）。

3.6 NAT4（地址相关映射） ↔ NAT4（地址相关映射）

核心原理

双方均为HardNAT，映射端口随目标IP动态变化，且过滤规则严格。打洞需满足“双方同时扫描到对方当前的动态端口”，而每个动态端口的有效期通常仅几十秒，命中率极低；同时高频扫描易触发运营商的DDoS防护机制，导致IP被临时封禁。

实战尝试（不推荐）

1. 双方启动Easytier，开启“深度端口扫描”模式（需手动设置扫描范围，如1000-65535）；
2. 双方同时向对方公网IP的全端口范围发起扫描请求，试图匹配对方的动态映射端口；
3. 若运气极佳，双方扫描到对方当前的动态端口，可建立连接；否则扫描持续数分钟后失败。

可行性结论

❌ 强烈不建议尝试，可行性低于10%，且存在IP被封禁的风险。推荐替代方案：① 让一方切换到EasyNAT网络（如连接手机热点）；② 使用中转服务器转发流量（Tailscale默认支持中转，稳定性高但延迟略高）；③ 升级IPv6网络。

四、打洞可行性总结表（详细版）

五、补充：IPv6替代方案（最优解）

若双方网络支持IPv6（可通过test-ipv6.com检测），优先放弃NAT打洞，直接使用IPv6通信：

1. 核心优势：IPv6为每个设备分配独立公网地址，无需NAT转换，直接通过IPv6地址建立连接，稳定性100%，延迟低于NAT打洞；
2. 实战步骤：
   1. 双方开启设备IPv6功能（电脑：设置-网络-属性，勾选IPv6；路由器：开启IPv6拨号，获取前缀）；
   2. 通过命令行获取自身IPv6地址（Windows：ipconfig；Linux：ifconfig）；
   3. 使用支持IPv6的工具（如Tailscale、SSH、FTP），直接输入对方IPv6地址建立连接，无需中转和打洞。
3. 注意事项：部分运营商IPv6地址为动态分配（重启路由器会变化），可在路由器中设置“IPv6地址绑定”，固定设备的IPv6后缀。

六、打洞核心规律与建议

1. EasyNAT之间（Type1-3）：打洞成功率高，优先使用Tailscale，操作简单且稳定，适合大多数个人/家庭场景；
2. EasyNAT↔HardNAT：优先尝试开启UPnP，其次使用Easytier，避免手动操作，减少风险；
3. HardNAT之间（Type4+）：放弃打洞，选择中转服务器或IPv6，既保证稳定性，又避免IP被封禁；
4. 实战优先级：检测NAT类型 → 尝试EasyNAT打洞 → 开启UPnP重试 → 切换IPv6 → 使用中转服务器。

一、踩坑现场：自信配置却遭遇 522 死循环

核心诉求很明确：利用腾讯云 EO 的免费计划，解决 Vercel 域名访问受阻的问题。我想当然地认为加速配置的关键就是 “回源 Host 填写 Vercel 提供的默认域名（如 xxx-project.vercel.app）”。

按照这个思路配置完成后，满心期待地等待部署结束，结果访问时直接弹出 522 错误 —— 服务器无响应。反复检查配置参数、重新部署项目，甚至更换网络环境测试，522 错误始终如影随形，完全摸不着头脑。

二、问题本质：多层 CDN 嵌套导致回源失效

我翻了一圈 CDN 加速的核心原理文档，再结合 Google 到的案例，终于理清了 522 错误的根源，本质是多层 CDN 嵌套引发的回源链路异常：

1. Vercel 默认域名的本质：xxx-project.vercel.app 并不是直接指向项目服务器的 “源站地址”，而是 Vercel 自家的 CDN 边缘节点域名。当我把这个域名填作 EO 的回源 Host 时，EO 实际是向 Vercel 的 CDN 节点发起回源请求，而非项目的真实源站。
2. 522 错误的触发逻辑：Vercel 的 CDN 节点会校验请求的 Host 头是否匹配其配置的域名，而 EO 向 Vercel CDN 发起的请求，其 Host 头与 Vercel 配置不兼容，再加上跨地域链路的延迟，最终导致回源超时，返回 522 错误。
3. 我的认知误区：之前误以为 EO 加速是简单的 “反代”，只要填个目标域名就行，忽略了源站是否本身已接入 CDN 这一关键前提。

三、正确配置：两步搞定 Vercel 加速

找到问题根源后，解决方案就清晰了 —— 跳过 Vercel 的 CDN 层，让 EO 直接指向项目的真实源站。具体配置步骤如下，同样适用于加速其他自带 CDN 的海外平台（如 Netlify、GitHub Pages）：

1. 获取 Vercel 真实回源 CNAME

首先要拿到 Vercel 项目的 “原始源站 CNAME”（非 CDN 域名），方法很简单：

• 登录 Vercel 控制台，添加你自己的域名，会给你一个Vercel的CNAME值；
• 这个CNAME值是 Vercel 源站得 CNAME，我们不要解析这个CNAME值;

2. 腾讯云 EO 核心配置

进入腾讯云 EO 控制台，添加与在Vercel添加的相同的自己的域名，重点修改以下两项：

3. 域名控制台添加 CNAME 解析

到域名控制台，添加 CNAME 解析，注意填的是EO平台给你的CNAME值，而不是Vercel给你的CNAME值。

四、拓展：海外 CDN 加速通用逻辑

这次踩坑让我总结出一个通用规律：当需要用 CDN 加速海外平台时，若目标平台自带 CDN，绝对不能直接用其公开的 CDN 域名作为回源地址。正确的逻辑是：

1. 在平台添加自己的域名，获取平台的CNAME值，不要做解析；
2. 在CDN控制台，回源地址填平台的CNAME值，Host 头填平台添加的域名；
3. 在域名控制台，添加CNAME解析，值填CDN给你的CNAME值;

希望这篇踩坑记能帮到同样被 Vercel 访问问题困扰的朋友，少走弯路，充分利用好免费的技术资源～

很多开发者在选型时会陷入纠结：到底该让数据库 “多干活”，还是让应用程序 “扛压力”？其实两者没有绝对优劣，核心取决于数据量、业务复杂度、实时性要求等关键因素。本文将从原理、场景、优缺点、实操建议四个维度，帮你彻底理清选型逻辑，避免踩坑。

一、先搞懂：两种分页的核心原理

在深入选型前，我们需要先明确两种分页的本质区别 ——数据过滤和分片的 “执行位置” 不同。

1. 数据库分页：数据库端 “按需取数”

数据库分页的核心是让数据库只返回当前页需要的数据，通过 SQL 语法（如 LIMIT/OFFSET、ROW_NUMBER()）或条件过滤，在数据查询阶段就完成 “筛选 + 分片”，最终只将单页数据（如 10 条、20 条）返回给应用程序。

典型实现示例：

• MySQL：SELECT * FROM orders WHERE status = 1 ORDER BY id DESC LIMIT 10 OFFSET 20;（查询第 3 页，每页 10 条待发货订单）
• PostgreSQL：SELECT * FROM orders WHERE status = 1 ORDER BY id DESC LIMIT 10 OFFSET 20;
• Oracle：SELECT * FROM (SELECT t.*, ROW_NUMBER() OVER(ORDER BY id DESC) rn FROM orders t WHERE status = 1) WHERE rn BETWEEN 21 AND 30;

其核心逻辑是：数据库利用索引快速过滤条件数据，再通过分页语法截取目标片段，减少数据传输和应用内存占用。

2. 程序分页：应用端 “全量处理”

程序分页的核心是先从数据库查询符合条件的全量数据，加载到应用程序内存中，再通过代码（如 Java 的 List.subList()、Python 的切片 [start:end]）实现分片，返回当前页数据。

典型实现示例（Java）：

// 1. 查全量数据（数据库返回所有待发货订单）
List<Order> allOrders = orderMapper.selectByStatus(1);
// 2. 程序分页：第3页（页码从1开始），每页10条
int pageNum = 3;
int pageSize = 10;
int start = (pageNum - 1) * pageSize;
int end = Math.min(start + pageSize, allOrders.size());
List<Order> pageOrders = allOrders.subList(start, end);

其核心逻辑是：数据库仅负责 “全量查询”，分页的计算、分片均在应用内存中完成，依赖应用的计算能力而非数据库。

二、核心选型：3 个维度定答案

选型的核心逻辑的是：让 “擅长的角色做擅长的事”—— 数据库擅长高效过滤、排序和海量数据存储，应用程序擅长复杂逻辑处理和灵活计算。具体可通过以下 3 个维度快速决策：

维度 1：数据量大小（最关键因素）

数据量直接决定了两种方案的可行性和性能上限：

• 小数据量（万级以内）：优先选程序分页。
  万级数据占用内存通常在几十 MB 以内（如每条数据 1KB，1 万条仅 10MB），应用程序完全可以承载。此时全量查询的 IO 开销远低于 “多次数据库分页查询”，且程序分页无需频繁与数据库交互，响应更连贯。

• 大数据量（10 万级以上）：必须选数据库分页。
  百万级 / 千万级数据全量查询会导致两个致命问题：① 数据库查询 + 数据传输耗时极长（可能秒级甚至分钟级）；② 应用内存溢出（OOM）—— 比如 100 万条数据约占 1GB 内存，远超普通应用的内存阈值。而数据库分页仅返回单页数据（几十条），内存占用可忽略，且依赖索引能快速响应。

维度 2：业务复杂度（分类 / 筛选逻辑）

业务逻辑的复杂程度决定了 “谁更适合处理分页前的过滤”：

• 简单逻辑（单一条件 / 多条件且可 SQL 表达）：优先选数据库分页。
  比如 “按订单状态筛选 + 按创建时间排序分页”“按地区 + 金额区间过滤分页”，这些逻辑可通过 SQL 的 WHERE子句 + 索引快速实现，数据库处理效率远高于应用程序全量加载后过滤。

• 复杂逻辑（多维度交叉 / 非 SQL 可表达）：优先选程序分页。
  比如 “按「金额区间（高 / 中 / 低）+ 配送区域 + 下单设备」三维交叉分类，且每个分类需独立分页”“按模糊匹配（如备注含特定关键词）+ 自定义规则（如 VIP 用户优先）筛选”，这些逻辑用 SQL 实现会非常繁琐（多层 CASE WHEN+GROUP BY），甚至无法实现，而应用程序可通过哈希表分组、流处理等方式灵活实现。

维度 3：业务场景（实时性 / 复用性要求）

• 实时性要求高（如订单列表、实时数据监控）：选数据库分页。
  数据库分页每次查询都是实时从数据库取数，能保证数据最新状态（如用户刚创建的订单立即显示）。而程序分页若不重新查询，会存在数据滞后问题。

• 需频繁复用数据（如多维度筛选、前端切换分类）：选程序分页。
  比如前端页面需要同时展示 “待付款”“待发货”“已完成” 三个分类的分页列表，程序分页可全量查询后在内存中缓存所有分类数据，用户切换分类时直接从内存取数，无需再次查询数据库；而数据库分页需要执行 3 次独立查询，增加数据库压力。

三、两种方案的优缺点深度对比

四、实操建议：避坑指南与优化技巧

选型后如何落地才能最大化性能？以下是两种方案的实操优化建议，避免踩常见坑：

数据库分页：3 个优化技巧，避免性能瓶颈

1. 优先用 “游标分页” 替代OFFSET深分页传统的 LIMIT OFFSET 分页在深分页场景（如 LIMIT 100000, 10）会出现性能问题 —— 数据库需要扫描前 100010 条数据才能返回目标 10 条。优化方案是 “游标分页”：按唯一有序字段（如 ID、创建时间戳）排序，通过 WHERE 条件替代 OFFSET：

   -- 上一页最大ID为10000，查询下一页（每页10条） SELECT * FROM orders WHERE status = 1 AND id > 10000 ORDER BY id ASC LIMIT 10;

   优点：利用索引直接定位起始位置，无需扫描前置数据，深分页性能无衰减。

2. 给过滤 / 排序字段加索引分页查询的 WHERE 条件字段（如 status、region）和 ORDER BY 字段（如 create_time、id）必须加索引，否则数据库会全表扫描，分页性能骤降。示例索引设计：

   -- 复合索引：适配“按状态筛选+按创建时间排序”的分页场景 CREATE INDEX idx_orders_status_create_time ON orders(status, create_time);

3. 合并统计查询，减少数据库交互若需要同时展示 “总条数”“总页数” 和 “当前页数据”，避免执行两次查询（一次查总数 + 一次查分页数据），可通过 SQL_CALC_FOUND_ROWS（MySQL）或子查询合并：

   -- MySQL：查询分页数据的同时获取总条数 SELECT SQL_CALC_FOUND_ROWS * FROM orders WHERE status = 1 ORDER BY id DESC LIMIT 10 OFFSET 20; SELECT FOUND_ROWS(); -- 获取总条数（无需再次扫描表）

程序分页：3 个避坑要点，保证稳定性

1. 加数据量限制，防止意外 OOM即使是小数据量场景，也需限制全量查询的最大条数，避免因业务异常导致数据量暴增（如用户查询 “所有历史订单” 时，意外返回 10 万条）。示例代码（Java）：

   // 限制最大查询条数为2万条 List<Order> allOrders = orderMapper.selectByCondition(condition, 20000);

2. 用高效数据结构，优化分页性能全量数据加载后，优先用 ArrayList（随机访问效率高）存储，分页时通过 subList() 分片（时间复杂度 O (1)），避免使用链表（随机访问效率低）。若需多分类分页，可提前用 HashMap 按分类键分组，后续分页直接从分组结果中取数：

   // 多分类分组+分页优化 Map<String, List<Order>> categoryMap = allOrders.stream() .collect(Collectors.groupingBy(order -> getCategoryKey(order))); // 自定义分类键 // 某分类分页 List<Order> categoryOrders = categoryMap.get("高金额-华东地区"); List<Order> pageOrders = categoryOrders.subList(start, end);

3. 缓存结果，减少重复查询若数据不频繁变化（如统计数据、历史订单），可将全量查询 + 分组后的结果缓存到 Redis（设置合理过期时间），下次分页直接从缓存取数，避免重复查询数据库。

五、进阶场景：混合分页方案（取长补短）

当遇到 “大数据量 + 复杂逻辑” 的场景（如 “千万级订单，需按三维交叉分类分页，且每个分类需实时展示最新数据”），单一方案无法满足需求，此时可采用混合分页方案：

核心思路：统计数预计算，详情页实时分页

1. 预计算分类统计：用定时任务（如 Quartz）或流处理（如 Flink）将复杂分类的统计结果（如 “华东地区 - 高金额订单数”“华北地区 - APP 下单订单数”）存储到 Redis 或宽表，避免实时全量计算。
2. 实时分页查详情：用户点击某个分类时，通过 “分类条件 + 游标分页” 查询该分类下的实时数据 —— 比如 “华东地区 - 高金额订单” 的分页，可通过 SQL WHERE 金额 > 1000 AND 地区 = '华东' AND id > 上一页最大ID LIMIT 10 实现，兼顾实时性和性能。

适用场景：

• 海量数据 + 复杂分类分页（如电商平台的订单多维度筛选分页）；
• 需兼顾实时性（详情数据）和性能（统计数据）的场景。

六、总结：选型决策表（直接套用）

最终结论

数据库分页和程序分页不是 “非此即彼” 的选择，而是 “按需适配” 的方案：

• 小数据量、复杂逻辑场景，让应用程序 “扛下” 分页，享受灵活和高效；
• 大数据量、简单逻辑场景，让数据库 “搞定” 分页，保证稳定和性能；
• 复杂场景下，用混合方案取长补短，兼顾业务需求和技术上限。

核心原则是：避免 “用数据库分页解决复杂逻辑”（逻辑繁琐、性能差），或 “用程序分页处理海量数据”（内存崩溃、响应慢），让技术方案适配业务场景，而非反过来让业务妥协于技术。

一、核心原因：浏览器的「默认 /favicon.ico 请求」

这是最根本的原因 ——浏览器会自动向网站根目录发送 /favicon.ico 请求，无论你是否在页面中引用：

• 即使你在 <head> 中写了 <link rel="icon" href="/static/favicon.ico">，部分浏览器（如 Chrome、Edge）仍会先尝试请求 /favicon.ico（根目录），失败后才会使用你指定的路径；
• 部署环境中，若根目录没有 favicon.ico，且你的页面引用有问题（如路径错误、缓存），就会出现「图标不显示，Network 面板看到 /favicon.ico 404」的现象。

二、其他辅助原因（部署环境常见）

1. 页面引用路径错误：

   • 本地开发时 url_for('static', filename='favicon.ico') 生成 /static/favicon.ico，但部署后若应用有「子路径前缀」（如 https://your-domain.com/app/），会生成 /app/static/favicon.ico，而浏览器仍请求 /favicon.ico；
   • 引用时用了相对路径（如 ../static/favicon.ico），部署后路径层级变化导致失效。

2. Nginx/Apache 反向代理配置覆盖：生产环境用反向代理时，可能配置了「根目录 favicon.ico 优先返回」，忽略 Flask 的静态文件路由：

   # 错误示例：Nginx 配置了根目录/favicon.ico，但实际文件不存在 location /favicon.ico { root /var/www/html/; # 若该目录没有favicon.ico，直接404 expires 7d; }

3. 浏览器缓存：之前访问过你的网站（或测试环境），浏览器缓存了「根目录 /favicon.ico 不存在」的结果，部署后即使修复了引用，仍会优先使用缓存。

三、3 种解决方法（从简单到彻底）

方法 1：确保页面中正确引用（最基础）

首先保证 <head> 中明确指定图标路径，覆盖浏览器默认行为：

<!-- templates/index.html（SPA入口页，全局生效） -->
<head>
  <!-- 核心：同时指定 rel="icon" 和 rel="shortcut icon"，兼容所有浏览器 -->
  <link rel="icon" href="{{ url_for('static', filename='favicon.ico') }}" type="image/x-icon">
  <link rel="shortcut icon" href="{{ url_for('static', filename='favicon.ico') }}" type="image/x-icon">
  <!-- 可选：添加不同尺寸/格式，适配更多场景（如PWA） -->
  <link rel="apple-touch-icon" sizes="180x180" href="{{ url_for('static', filename='apple-touch-icon.png') }}">
</head>

• 关键：用 url_for('static', filename='favicon.ico') 动态生成路径，避免硬编码（适配部署后的子路径前缀）；
• 验证：部署后查看页面源码，确认 href 是正确的 https://your-domain.com/static/favicon.ico（而非 /favicon.ico）。

方法 2：路由重定向（让根目录请求指向 static）

即使浏览器请求 /favicon.ico，也通过 Flask 路由重定向到 static 目录的文件，彻底解决默认请求问题：

# app.py（在create_app()中添加路由）
def create_app(config_name=None):
    app = Flask(__name__)
    
    # 新增：根目录favicon.ico请求 → 重定向到static目录
    @app.route('/favicon.ico')
    def favicon_redirect():
        from flask import redirect, url_for
        return redirect(url_for('static', filename='favicon.ico'))
    
    # 其他配置（蓝图、错误处理等）...
    return app

• 效果：访问 /favicon.ico 会自动跳转到 /static/favicon.ico，浏览器能正确获取图标；
• 优势：无需修改 Nginx 配置，纯 Flask 代码解决，适配所有部署环境。

方法 3：Nginx 配置（生产环境最优，性能最高）

生产环境用 Nginx 反向代理时，直接让 Nginx 处理 favicon.ico 请求（不经过 Flask），提升性能：

server {
    listen 80;
server_name your-domain.com;

    # 核心配置：/favicon.ico 直接指向 static 目录的文件
    location /favicon.ico {
        # 注意：root 是项目根目录（static的上级目录），不是static目录本身
        root /path/to/your_project/;  # 示例：/var/www/music_project/
        # 实际文件路径 = root + static/favicon.ico → /var/www/music_project/static/favicon.ico
        try_files /static/favicon.ico =404;  # 尝试读取文件，不存在返回404
        expires 7d;  # 缓存7天，减少重复请求
        add_header Cache-Control "public";
    }

    # 静态文件配置（已有的）
    location /static/ {
        root /path/to/your_project/;
        expires 7d;
    }

    # 动态请求转发给Flask
    location / {
        proxy_pass http://127.0.0.1:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

• 关键：root 指向项目根目录（如 /var/www/music_project/），try_files /static/favicon.ico 表示「在 root 目录下查找 static/favicon.ico 文件」；
• 优势：Nginx 直接返回静态文件，比 Flask 路由重定向性能更高，适合高并发场景。

四、部署后验证步骤（确保生效）

1. 清除浏览器缓存：按 Ctrl+Shift+R（Chrome）强制刷新，或打开「开发者工具 → Network → 勾选 Disable cache」后刷新；

2. 查看 Network 面板：

   • 搜索 favicon，查看请求路径：应为 /static/favicon.ico 或 /favicon.ico（状态码 200）；
   • 若仍为 404，检查路径是否正确（如 static 目录是否上传到服务器、文件权限是否为可读）；

3. 直接访问验证：

   • 访问 https://your-domain.com/static/favicon.ico，能看到图标说明文件存在且路径正确；
   • 访问 https://your-domain.com/favicon.ico，能看到图标说明重定向 / Nginx 配置生效。

五、常见坑点排查

1. 文件路径错误：

   • 服务器上的 static 目录是否和本地一致？（如本地 static/favicon.ico，服务器是否误放在 static/icons/favicon.ico）；
   • 文件名是否大小写敏感？（Linux 服务器区分 favicon.ico 和 Favicon.ico，Windows 不区分）。

2. 文件权限问题：

   • 服务器上的 favicon.ico 文件是否有「读权限」？（执行 chmod 644 /path/to/your_project/static/favicon.ico 赋予权限）；
   • static 目录是否有「执行权限」？（执行 chmod 755 /path/to/your_project/static，确保浏览器能进入目录）。

3. 子路径部署场景：若应用部署在子路径（如 https://your-domain.com/music/），需注意：

   • 页面引用用 url_for('static', filename='favicon.ico') 会自动生成 /music/static/favicon.ico；

   • Nginx 配置需调整 root 或 alias
     例如：

     location /music/favicon.ico { alias /path/to/your_project/static/favicon.ico; # 直接指向文件 expires 7d; }

总结

部署后浏览器从根目录获取 favicon.ico 是「浏览器默认行为」导致的，解决核心是：

1. 页面中明确引用 static/favicon.ico（用 url_for 动态生成路径）；
2. 用「Flask 路由重定向」或「Nginx 配置」让 /favicon.ico 指向正确文件；
3. 清除缓存并验证文件路径和权限。

按方法 1 + 方法 2（或方法 1 + 方法 3）配置后，所有浏览器都能正确获取图标，不会再出现「根目录请求 404」的问题。

一、核心原理：为什么需要特殊配置？

当用户访问经过 EdgeOne 加速的网站时，请求会先经过 EdgeOne 海外节点（反向代理），再由节点转发到源站 Nginx。此时 Nginx 会默认将「直接连接的客户端 IP」（即 EdgeOne 节点 IP）识别为用户 IP，而非真实的用户公网 IP。

解决思路的核心是「信任代理」：

1. EdgeOne 节点会在转发请求时，通过 X-Forwarded-For 头携带用户真实 IP（格式：用户真实IP, 节点IP1, 节点IP2）；
2. 配置 Nginx 信任所有 EdgeOne 节点 IP，让 Nginx 从 X-Forwarded-For 头中自动跳过节点 IP，提取最原始的用户真实 IP。

关键提示：本文以「海外业务场景」为例，适配 CentOS 系统 + Nginx + 宝塔面板，其他系统（如 Ubuntu）或 Web 服务器（如 Apache）可参考原理调整。

二、前置准备：确认 EdgeOne 基础配置

在配置 Nginx 前，需先确保 EdgeOne 已正确配置「回源透传」，否则节点不会携带用户真实 IP 信息：

1. 登录 EdgeOne 控制台，进入目标站点的「回源配置」；
2. 开启「HTTP 头配置」，确认已添加「透传 X-Forwarded-For 头」（默认开启，若未开启需手动添加）；
3. 关闭「源站保护」功能（重要！开启后无法获取完整节点 IP 段，配置完成后可重新开启）。

三、手动配置：快速实现真实 IP 解析

若业务规模较小，可先通过手动配置验证效果，步骤如下：

3.1 获取 EdgeOne 海外节点 IP 段

EdgeOne 提供官方接口用于获取最新节点 IP 段，海外 IPv4 段专属获取方式：

1. 本地浏览器访问接口：https://api.edgeone.ai/ips?version=v4&area=overseas（仅返回海外节点 IP 段，精准适配海外业务）；
2. 复制页面中所有 IP 段（纯文本格式，如 43.174.0.0/15），保存到本地文档。

注意事项：接口返回的 IP 段会不定期更新，建议每 1-2 个月重新获取一次，避免因 IP 段过期导致解析失效。

3.2 配置 Nginx 信任节点 IP 段

通过宝塔面板修改 Nginx 配置（手动操作更直观，适合新手）：

1. 登录宝塔面板，进入「网站」→ 目标站点（如 music.686909.xyz）→ 「配置文件」；
2. 在 server 块顶部添加「节点 IP 段信任配置」，完整配置示例如下（重点关注标记内内容）：

server
{
    listen 80;
    listen 443 ssl;
    listen 443 quic;
    http2 on;
    server_name music.686909.xyz;

    # ====== EDGEONE_IP_START 标记（后续自动化需用到）======
    # EdgeOne 海外节点 IP 段（手动复制接口返回内容）
    set_real_ip_from 43.174.0.0/15;
    set_real_ip_from 45.12.0.0/16;
    set_real_ip_from 45.65.0.0/16;
    set_real_ip_from 45.113.0.0/16;
    set_real_ip_from 52.58.0.0/15;
    # ... 此处省略其他从接口获取的 IP 段，需完整粘贴 ...
    set_real_ip_from 217.160.0.0/16;
    # ====== EDGEONE_IP_END 标记（后续自动化需用到）======

    # 真实 IP 解析核心规则
    real_ip_header X-Forwarded-For;        # 从该头提取真实 IP
    real_ip_recursive on;                  # 递归跳过信任的节点 IP
    set_real_ip_from 127.0.0.1;            # 额外信任本地代理（避免干扰）

    # 以下为原有配置（SSL、反向代理等，无需修改）
    index index.html index.htm default.htm default.html;
    root /www/wwwroot/music;
    ssl_certificate    /www/server/panel/vhost/cert/music/fullchain.pem;
    ssl_certificate_key    /www/server/panel/vhost/cert/music/privkey.pem;
    # ... 其他配置省略 ...
}

1. 点击「保存」，然后在宝塔面板「服务」中重启 Nginx，配置生效。

3.3 验证配置效果

配置完成后，通过以下步骤确认真实 IP 是否解析成功：

1. 用海外网络访问目标网站（如通过海外 VPN 或在线代理工具）；
2. 在宝塔面板进入「网站」→ 目标站点 → 「日志」，查看访问日志（如 music.log）；
3. 日志中「IP」字段若显示为非 EdgeOne 网段的公网 IP（可通过 IP138 验证归属地），说明解析成功。

四、自动化方案：IP 段自动更新（运维必备）

手动更新 IP 段效率低且易遗漏，通过「Shell 脚本 + 定时任务」可实现全自动更新，核心逻辑：定期从官方接口获取最新 IP 段 → 自动替换 Nginx 配置 → 验证并重启 Nginx。

4.1 编写自动更新脚本

创建脚本 update_edgeone_ips.sh，上传到服务器 /root/ 目录，脚本已适配海外节点和宝塔面板，关键部分已加注释（需替换脚本中 NGINX_CONF 为你的站点配置路径）：

#!/bin/bash
# ==============================================
# EdgeOne 海外节点 IP 段自动更新脚本（Nginx 适配版）
# 功能：接口获取IP段 → 替换配置 → 验证重启 → 备份回滚
# 适配：CentOS + 宝塔面板 + 海外业务
# ==============================================

# ---------------------- 核心参数（需根据实际调整）----------------------
NGINX_CONF="/www/server/panel/vhost/nginx/python_music.conf"  # 你的站点Nginx配置路径
IP_API="https://api.edgeone.ai/ips?version=v4&area=overseas"  # 海外IPv4专属接口
TIMEOUT=30  # 接口超时时间（秒）
RETRY=3     # 接口失败重试次数
# ---------------------------------------------------------------------------

# 临时文件（规避Sed长字符串语法问题）
TMP_IP_FILE=$(mktemp)
TMP_NGINX_CONF=$(mktemp)
BACKUP_CONF="${NGINX_CONF}.bak.$(date +%Y%m%d)"  # 带日期的配置备份文件

# 1. 接口获取IP段（适配海外网络，带重试+证书兼容）
echo "[$(date +'%Y-%m-%d %H:%M:%S')] 从官方接口获取EdgeOne海外IP段（最多重试$RETRY次）..."
for ((i=1; i<=$RETRY; i++)); do
    # curl参数说明：跳过证书校验、设置超时、失败重试
    curl -s --connect-timeout 10 --max-time $TIMEOUT \
         --retry $RETRY --retry-delay 3 \
         --insecure \
         "$IP_API" > "$TMP_IP_FILE"
    
    # 验证获取结果：非空且包含标准IPv4网段格式
    if [ -s "$TMP_IP_FILE" ] && grep -qE '^([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]{1,2}$' "$TMP_IP_FILE"; then
        echo "[$(date +'%Y-%m-%d %H:%M:%S')] ✅ 第$i次尝试成功，获取到有效IP段"
        break
    else
        echo "[$(date +'%Y-%m-%d %H:%M:%S')] ❌ 第$i次尝试失败，正在重试..."
        if [ $i -eq $RETRY ]; then
            echo "[$(date +'%Y-%m-%d %H:%M:%S')] ❌ 所有重试失败，无法获取IP段，退出脚本"
            rm -f "$TMP_IP_FILE" "$TMP_NGINX_CONF"
            exit 1
        fi
    fi
done

# 2. 过滤无效IP段并生成Nginx格式配置
echo "[$(date +'%Y-%m-%d %H:%M:%S')] 过滤无效IP段并生成配置..."
# 仅保留标准IPv4网段，剔除异常内容
grep -E '^([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]{1,2}$' "$TMP_IP_FILE" > "$TMP_IP_FILE.tmp"
mv "$TMP_IP_FILE.tmp" "$TMP_IP_FILE"

# 检查过滤后是否有有效IP段
if [ ! -s "$TMP_IP_FILE" ]; then
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] ❌ 过滤后无有效IP段，退出脚本"
    rm -f "$TMP_IP_FILE" "$TMP_NGINX_CONF"
    exit 1
fi

# 生成带标记的完整IP配置（写入临时文件，避免Sed拼接过长）
IP_CONFIG_FILE=$(mktemp)
echo "# ====== EDGEONE_IP_START 自动更新标记（请勿删除）======" > "$IP_CONFIG_FILE"
echo "# 自动更新时间：$(date +'%Y-%m-%d %H:%M:%S')" >> "$IP_CONFIG_FILE"
echo "# EdgeOne 海外节点IP段（从官方接口获取）" >> "$IP_CONFIG_FILE"
# 将IP段转换为Nginx的set_real_ip_from格式
awk '{print "    set_real_ip_from " $0 ";"}' "$TMP_IP_FILE" >> "$IP_CONFIG_FILE"
echo "# ====== EDGEONE_IP_END 自动更新标记（请勿删除）======" >> "$IP_CONFIG_FILE"

# 3. 备份原Nginx配置（避免替换失败导致服务异常）
cp "$NGINX_CONF" "$BACKUP_CONF"
echo "[$(date +'%Y-%m-%d %H:%M:%S')] ✅ 原配置已备份至：$BACKUP_CONF"

# 4. 替换配置文件中的IP段（文件分段拼接，兼容长内容）
echo "[$(date +'%Y-%m-%d %H:%M:%S')] 开始替换Nginx配置中的IP段..."
# 步骤1：提取标记前的内容
sed -n '/# ====== EDGEONE_IP_START 自动更新标记（请勿删除）======/q;p' "$NGINX_CONF" > "$TMP_NGINX_CONF"
# 步骤2：插入新生成的IP配置
cat "$IP_CONFIG_FILE" >> "$TMP_NGINX_CONF"
# 步骤3：提取标记后的内容（排除结束标记本身，避免重复）
sed -n '/# ====== EDGEONE_IP_END 自动更新标记（请勿删除）======/,$!d;/# ====== EDGEONE_IP_END 自动更新标记（请勿删除）======/!p' "$NGINX_CONF" >> "$TMP_NGINX_CONF"

# 覆盖原配置并保持文件权限（宝塔默认Nginx配置权限为644）
cp "$TMP_NGINX_CONF" "$NGINX_CONF"
chmod 644 "$NGINX_CONF"

# 5. 验证配置替换结果
if grep -q "set_real_ip_from 43.174.0.0/15;" "$NGINX_CONF"; then
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] ✅ IP段成功写入Nginx配置"
else
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] ❌ IP段写入失败，正在恢复原配置..."
    cp "$BACKUP_CONF" "$NGINX_CONF"
    rm -f "$TMP_IP_FILE" "$TMP_NGINX_CONF" "$IP_CONFIG_FILE"
    exit 1
fi

# 6. 测试Nginx配置并重启服务
echo "[$(date +'%Y-%m-%d %H:%M:%S')] 测试Nginx配置语法有效性..."
if /www/server/nginx/sbin/nginx -t; then
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] ✅ 配置语法正确，重启Nginx服务..."
    /www/server/nginx/sbin/nginx -s reload
    IP_COUNT=$(wc -l < "$TMP_IP_FILE")
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] 🎉 全部操作完成！本次共更新$IP_COUNT个海外IP段"
else
    echo "[$(date +'%Y-%m-%d %H:%M:%S')] ❌ 配置语法错误，正在恢复原配置..."
    cp "$BACKUP_CONF" "$NGINX_CONF"
    /www/server/nginx/sbin/nginx -s reload
    rm -f "$TMP_IP_FILE" "$TMP_NGINX_CONF" "$IP_CONFIG_FILE"
    exit 1
fi

# 清理临时文件
rm -f "$TMP_IP_FILE" "$TMP_NGINX_CONF" "$IP_CONFIG_FILE"

4.2 脚本授权与测试运行

通过 SSH 工具登录服务器（如 Xshell、FinalShell），执行以下命令完成脚本授权和手动测试，确保脚本可正常运行：

# 1. 给脚本添加可执行权限（仅需执行一次）
chmod +x /root/update_edgeone_ips.sh

# 2. 手动执行脚本，验证流程是否正常
/root/update_edgeone_ips.sh

成功运行的输出示例：

[2025-12-01 09:30:00] 从官方接口获取EdgeOne海外IP段（最多重试3次）...
[2025-12-01 09:30:02] ✅ 第1次尝试成功，获取到有效IP段
[2025-12-01 09:30:02] 过滤无效IP段并生成配置...
[2025-12-01 09:30:02] ✅ 原配置已备份至：/www/server/panel/vhost/nginx/python_music.conf.bak.20251201
[2025-12-01 09:30:03] 开始替换Nginx配置中的IP段...
[2025-12-01 09:30:03] ✅ IP段成功写入Nginx配置
[2025-12-01 09:30:04] 测试Nginx配置语法有效性...
nginx: the configuration file /www/server/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /www/server/nginx/conf/nginx.conf test is successful
[2025-12-01 09:30:04] ✅ 配置语法正确，重启Nginx服务...
[2025-12-01 09:30:05] 🎉 全部操作完成！本次共更新36个海外IP段

常见测试失败处理：

若提示 “接口访问失败”，可先执行 curl -v --insecure https://api.edgeone.ai/ips?version=v4&area=overseas 查看具体错误（如防火墙拦截、DNS 解析异常），针对性解决后再重新测试。

4.3 配置定时任务（实现每月自动更新）

手动执行脚本可验证效果，但为避免 IP 段过期，需配置定时任务每月自动更新，通过宝塔面板操作更直观：

1. 登录宝塔面板，进入「计划任务」模块，点击「添加任务」；
2. 任务类型：选择「Shell 脚本」（核心类型，执行服务器命令）；
3. 执行周期：选择「每月」，日期设为「1」，时间选凌晨空闲时段（如 03:00，避免影响业务）；
4. 脚本路径：填写 /root/update_edgeone_ips.sh（脚本实际存放路径）；
5. 日志设置：勾选「保存日志」，日志路径默认即可（便于后续排查执行情况）；
6. 点击「添加」，系统会自动生成定时任务，每月 1 号凌晨自动执行 IP 段更新。

⚠️ 注意事项：添加定时任务后，建议手动执行一次「测试」按钮，确认任务可正常触发脚本，避免因路径错误、权限问题导致定时执行失败。

五、常见问题与故障排查

配置过程中可能遇到接口访问失败、真实 IP 解析无效等问题，以下是高频问题的解决方案，按排查优先级排序：

5.1 接口无法获取 IP 段（脚本第一步失败）

5.2 真实 IP 解析不生效（日志仍为节点 IP）

这是最常见的问题，按以下步骤逐步排查，可覆盖 90% 以上场景：

1. 检查 EdgeOne 透传配置：登录 EdgeOne 控制台，确认「回源配置」→「HTTP 头配置」中已开启「透传 X-Forwarded-For 头」，且未开启「源站保护」（开启后会隐藏节点 IP）；
2. 验证 Nginx 核心规则：确保 real_ip_header X-Forwarded-For; 和 real_ip_recursive on; 已配置，且位于所有 set_real_ip_from 规则之后（顺序错误会导致解析失效）；
3. 确认 IP 段完整性：在访问日志中复制记录的 “节点 IP”，通过 EdgeOne 控制台「工具」→「IP 归属查询」确认是否为 EdgeOne 节点 IP，若不在配置的 IP 段中，说明 IP 段未更新，需重新执行脚本；
4. 重启 Nginx 服务：配置修改后未重启服务，执行 www/server/nginx/sbin/nginx -s reload 确保配置生效。

5.3 脚本替换配置后 Nginx 启动失败

主要原因是配置语法错误，脚本已内置回滚机制，会自动恢复原配置，可通过以下方式定位问题：

1. 查看 Nginx 错误日志：执行 cat /www/server/nginx/logs/error.log，重点关注 “syntax error” 相关内容；
2. 检查 IP 段格式：手动打开 Nginx 配置文件，确认标记内的 set_real_ip_from 规则是否均为 set_real_ip_from x.x.x.x/x; 格式，无多余空格、逗号；
3. 恢复原配置：若脚本未自动回滚，执行 cp 备份文件路径 原配置路径（如 cp /www/server/panel/vhost/nginx/python_music.conf.bak.20251201 /www/server/panel/vhost/nginx/python_music.conf），重启 Nginx 即可恢复服务。

六、总结与扩展

本文提供的 EdgeOne 海外节点真实 IP 解析方案，核心是「信任代理节点 IP + 提取 X-Forwarded-For 头真实 IP」，通过 “手动配置验证 + 自动化脚本更新” 的组合，既保证了新手可快速上手，又解决了运维过程中 IP 段过期的痛点。

方案扩展场景

1. 多站点适配：若服务器部署多个站点，可复制脚本并修改 NGINX_CONF 路径，或在脚本中添加多路径数组循环处理；
2. IPv6 场景：将脚本中 IP_API 改为 https://api.edgeone.ai/ips?version=v6&area=overseas，同时在 Nginx 配置中添加 real_ip_header X-Forwarded-For;（IPv6 解析规则与 IPv4 一致）；
3. 非宝塔环境：修改脚本中 Nginx 启动命令（如 systemctl restart nginx）和配置路径（如 /etc/nginx/conf.d/your_site.conf）即可适配。

通过本文方案配置后，Nginx 日志将准确记录用户真实 IP，可正常开展地域访问统计、异常 IP 拦截等运维工作，且每月自动更新 IP 段，实现 “一次配置，长期稳定” 的效果。

🌐 项目简介

这是一个基于Flask框架开发的个人音乐播放器项目，旨在模拟网易云音乐的核心功能并提供简洁的用户体验。该项目集成了网易云音乐API，支持音乐搜索、歌单管理、用户认证等功能，为音乐爱好者提供一个轻量级的音乐播放和管理平台。

🌟 核心亮点

• 完全免费：基于网易云音乐资源爬虫，无付费门槛
• 安全稳定：依托网易云底层资源，播放与数据传输更可靠
• 全端适配：自适应各类分辨率设备，手机、电脑端体验一致
• 开放接口：提供公开 API 接口，支持二次开发（详见「关于我们」页面）
• 轻量高效：无冗余功能，聚焦核心需求，加载速度快

🚀 功能特性

• 精准音乐搜索：支持按歌曲名、歌手检索网易云资源，分页展示结果，快速定位目标音乐
• 灵活歌单管理：创建、编辑、删除个人歌单，自由添加 / 移除歌曲，支持自定义歌单封面
• 安全用户系统：完整的注册、登录与身份验证机制，保障个人歌单与播放数据安全
• 历史记录管理：自动记录播放轨迹，支持查看最近播放，内置数据清理工具优化性能
• 热门音乐推荐：同步网易云热门歌单，一键发现优质音乐，拓宽听歌边界
• 基础播放功能：支持歌曲播放 / 暂停、实时歌词显示、封面查看，满足日常听歌需求

• 🛠 技术栈选型

• 后端框架：Flask 2.x（Python）

• 数据库：MySQL 5.7+（自定义工具类操作）
• 前端技术：HTML5 + CSS3 + JavaScript
• API 集成：网易云音乐非官方 API（爬虫获取）
• 认证机制：Session-based 身份认证
• 配置管理：环境变量 + 配置文件双模式
• 工具依赖：自定义数据库、文件及 JS 操作工具类

💡 项目心得

Flask 框架在 API 开发和小型网站场景中优势明显，开发效率高、配置灵活。但当项目业务复杂度提升或页面交互增多时，其灵活性会带来代码耦合度高的问题。
此外，不建议用原生 CSS/JS 开发 SPA 类型网站，后续维护成本高、功能扩展难度大，推荐引入前端框架拆分组件。
这是我的第一个 Flask 项目，可能存在潜在 bug，欢迎大家提交 Issues 反馈问题，或提出优化建议，共同完善项目～

加/ 是根路径相对定位，不加/ 是当前路径相对定位，最终指向的 URL 会完全不同

1. 加 /：从网站根目录开始找

href=”/xxx” 中的 / 代表网站的根目录（比如 https://www.example.com/） ，不管当前页面在哪个层级，都会从根目录出发拼接路径。示例：

• 网站根目录：https://www.example.com/
• 当前页面 URL：https://www.example.com/a/b/c.html
• href=”/about” → 最终指向：https://www.example.com/about
• href=”/static/css/style.css” → 最终指向：https://www.example.com/static/css/style.css

2. 不加 /：从当前页面所在目录开始找

href=”xxx” 是相对于当前页面的 URL 路径拼接，相当于 “在当前文件夹里找目标资源”。示例（和上面同个网站、同个当前页面）：

• 当前页面 URL：https://www.example.com/a/b/c.html （当前目录是 /a/b/）
• href=”about” → 最终指向：https://www.example.com/a/b/about
• href=”static/css/style.css” → 最终指向：https://www.example.com/a/b/static/css/style.css

尾部/的作用

核心区别是是否默认指向 “目录” ，会影响服务器解析和最终跳转的 URL

1. 末尾加 /：表示 “这是一个目录”

当 URL 末尾带 / 时，浏览器和服务器会默认把它当作目录路径，优先查找目录下的默认索引文件（如 index.html、index.php 等）。示例：

• href=”https://www.example.com/about/“ → 服务器会去 about 目录下找默认索引文件（如 about/index.html）
• 若当前页面是 https://www.example.com/a/ ， href=”b/“ → 指向 https://www.example.com/a/b/ （目录）

2. 末尾不加 /：表示 “可能是文件，也可能是目录”

末尾不带 / 时，服务器会先尝试当作文件路径查找；若找不到对应文件，会自动做 “重定向”—— 在末尾加上 /，再按目录查找默认索引文件。示例：

• href=”https://www.example.com/about“ → 服务器先找 about 文件，找不到就重定向到 https://www.example.com/about/
• 若当前页面是 https://www.example.com/a/ ， href=”b” → 先找 a/b 文件，找不到就重定向到 https://www.example.com/a/b/

一、文件与目录操作命令（最基础高频）

1. ls - 列出目录内容

功能：列出指定目录下的文件 / 目录，默认列出当前目录。核心参数：

• -l（长格式）：显示文件权限、所有者、大小、修改时间等详细信息。
• -a（all）：显示所有文件（含隐藏文件，以.开头）。
• -h（human-readable）：以人类可读格式显示文件大小（如 KB、MB）。
• -r（reverse）：反向排序（默认按字母升序）。
• -t（time）：按修改时间排序（最新在前）。

示例：

ls -lha  # 长格式显示当前目录所有文件，含隐藏文件，大小人性化显示
ls /home/user  # 列出指定目录/home/user下的内容

2. cd - 切换工作目录

功能：切换当前终端的工作目录。核心用法：

• cd 目录路径：切换到指定目录（绝对路径 / 相对路径）。
• cd ~ 或 cd：切换到当前用户的家目录（如/home/ubuntu）。
• cd ..：切换到上级目录。
• cd -：切换到上一次所在的目录。

示例：

cd /etc/nginx  # 绝对路径切换到nginx配置目录
cd ../logs  # 相对路径切换到上级目录的logs子目录
cd ~/Documents  # 切换到家目录的Documents文件夹

3. pwd - 显示当前工作目录

功能：打印当前终端所在的绝对路径。

示例：

pwd  # 输出如：/home/user/Documents

4. mkdir - 创建目录

功能：创建新目录。核心参数：

• -p（parents）：递归创建多级目录（父目录不存在时自动创建）。
• -m（mode）：创建时指定目录权限（如 755）。

示例：

mkdir test  # 创建单个目录test
mkdir -p data/logs  # 递归创建data目录及子目录logs
mkdir -m 700 private  # 创建权限为700（仅所有者可读写执行）的目录

5. rm - 删除文件 / 目录

功能：删除文件或目录，慎用（无回收站，删除后难恢复）。核心参数：

• -f（force）：强制删除（忽略不存在的文件，不提示）。
• -r（recursive）：递归删除目录及目录内所有内容（删除目录必须用）。
• -i（interactive）：删除前提示确认（默认部分系统启用）。

示例：

rm file.txt  # 删除单个文件file.txt
rm -rf dir/  # 强制递归删除dir目录及所有内容（高危命令，谨慎使用）
rm -i *.log  # 删除所有.log文件，删除前逐一提示

6. cp - 复制文件 / 目录

功能：复制文件或目录到指定位置。核心参数：

• -r（recursive）：递归复制目录（复制目录必须用）。
• -p（preserve）：保留文件的权限、所有者、修改时间等属性。
• -f（force）：强制覆盖目标文件（无需提示）。
• -a（archive）：等价于-dR --preserve=all，适用于备份（保留所有属性 + 递归复制）。

示例：

cp file.txt /home/user/  # 复制file.txt到/home/user目录下
cp -r dir/ /backup/  # 递归复制dir目录到/backup目录下
cp -a docs/ docs_backup/  # 备份docs目录，保留所有属性

7. mv - 移动 / 重命名文件 / 目录

功能：移动文件 / 目录到指定位置，或重命名文件 / 目录。核心参数：

• -f（force）：强制覆盖目标文件（无提示）。
• -i（interactive）：覆盖前提示确认。

示例：

mv file.txt newfile.txt  # 重命名file.txt为newfile.txt
mv data/ /home/user/  # 移动data目录到/home/user目录下
mv -f old.log /tmp/  # 强制移动old.log到/tmp目录，覆盖已存在文件

8. touch - 创建空文件 / 修改文件时间戳

功能：创建空白文件，或更新文件的访问时间、修改时间（默认两者都更新）。核心参数：

• -d（date）：指定时间戳（如2024-01-01 10:00）。
• -m（modify）：仅更新修改时间。
• -a（access）：仅更新访问时间。

示例：

touch test.txt  # 创建空文件test.txt
touch -d "2024-05-20 14:30" old.txt  # 修改old.txt的时间戳为指定时间
touch -a readme.md  # 仅更新readme.md的访问时间

9. cat - 查看文件内容

功能：连接并打印文件内容（适合查看小文件）。核心参数：

• -n（number）：显示行号。
• -b（number-nonblank）：仅对非空行显示行号。
• -T（show-tabs）：显示制表符（Tab）为^I。

示例：

cat /etc/hosts  # 查看hosts文件内容
cat -n test.txt  # 显示test.txt内容并标注行号
cat file1.txt file2.txt > file3.txt  # 合并file1和file2的内容到file3（覆盖）

10. more/less - 分页查看大文件

功能：分页显示文件内容（适合大文件，避免内容刷屏）。核心区别：

• more：仅支持向下滚动（空格翻页，Enter 换行，q 退出）。
• less：支持上下滚动、搜索（更灵活，/关键词搜索，n下一个，q退出）。

示例：

more /var/log/syslog  # 分页查看系统日志（仅向下翻）
less /etc/passwd  # 分页查看用户配置文件（支持上下滚动和搜索）

11. head/tail - 查看文件首尾内容

功能：head查看文件开头部分，tail查看文件结尾部分。核心参数：

• -n N：显示前 N 行（head）或后 N 行（tail），默认 10 行。
• -f（follow）：实时跟踪文件更新（tail 专属，适合查看日志）。

示例：

head -5 /etc/passwd  # 查看passwd文件前5行
tail -10 /var/log/nginx/access.log  # 查看nginx访问日志最后10行
tail -f /var/log/syslog  # 实时跟踪系统日志更新（按Ctrl+C退出）

12. find - 查找文件 / 目录

功能：按路径、名称、大小、时间等条件查找文件 / 目录。核心参数：

• -name "文件名"：按名称查找（支持通配符*、?）。
• -path "路径"：按路径查找。
• -size [+/-]大小：按大小查找（如+100M大于 100MB，-10K小于 10KB）。
• -mtime [+/-]天数：按修改时间查找（如+7修改时间超过 7 天，-124 小时内修改）。
• -type f/d：指定查找类型（f 文件，d 目录）。
• -exec 命令 {} \;：对查找结果执行指定命令（{}代指查找结果）。

示例：

find /home -name "*.txt"  # 在/home目录下查找所有.txt文件
find /etc -type d -name "nginx"  # 在/etc目录下查找名为nginx的目录
find /var/log -size +50M  # 在/var/log目录下查找大于50MB的文件
find /tmp -mtime +3 -exec rm -rf {} \;  # 删除/tmp目录下3天前修改的文件/目录

13. grep - 文本搜索工具

功能：在文件或命令输出中搜索匹配的字符串 / 正则表达式。核心参数：

• -i（ignore-case）：忽略大小写。
• -n（line-number）：显示匹配行的行号。
• -v（invert-match）：反向匹配（显示不包含关键词的行）。
• -r（recursive）：递归搜索目录下所有文件。
• -E（extended-regexp）：支持扩展正则表达式（无需转义+、|等）。

示例：

grep "error" /var/log/syslog  # 在系统日志中搜索"error"字符串
grep -in "warning" /etc/nginx/nginx.conf  # 忽略大小写搜索nginx配置文件中的"warning"，显示行号
grep -r "test" /home/user  # 递归搜索/home/user目录下所有文件中的"test"
ps aux | grep "nginx"  # 结合管道，搜索nginx进程

二、文件权限与用户管理命令

1. chmod - 修改文件 / 目录权限

功能：修改文件或目录的访问权限（所有者、组用户、其他用户的读 / 写 / 执行权限）。权限表示：

• 数字法（常用）：r=4、w=2、x=1，权限组合为三者之和（如755= 所有者 rwx，组用户 rx，其他用户 rx）。
• 符号法：u（所有者）、g（组用户）、o（其他用户）、a（所有用户）；+（添加权限）、-（移除权限）、=（设置权限）。

示例：

chmod 755 script.sh  # 设为所有者可读写执行，其他用户只读执行
chmod 644 file.txt  # 设为所有者读写，其他用户只读（文件常用权限）
chmod u+x test.sh  # 给所有者添加执行权限
chmod g-w dir/  # 给组用户移除写权限

2. chown - 修改文件 / 目录所有者

功能：修改文件或目录的所有者（需 root 权限或文件所有者）。核心用法：chown [所有者][:组] 文件/目录

示例：

sudo chown user:user file.txt  # 将file.txt的所有者和组改为user
sudo chown root /home/user/test.sh  # 将test.sh的所有者改为root
sudo chown -R www-data:www-data /var/www  # 递归修改/var/www目录的所有者为www-data（web服务常用）

3. chgrp - 修改文件 / 目录所属组

功能：单独修改文件或目录的所属组（chown可替代，但该命令更专注）。

示例：

chgrp users file.txt  # 将file.txt的所属组改为users
chgrp -R staff /home/shared  # 递归修改/shared目录的所属组为staff

4. useradd - 创建新用户

功能：创建 Linux 系统用户（需 root 权限）。核心参数：

• -m（create-home）：自动创建用户家目录（如/home/用户名）。
• -s shell路径：指定用户登录 shell（如/bin/bash，默认/bin/sh）。
• -g 组名：指定用户初始组。
• -G 组名1,组名2：指定用户附加组。

示例：

sudo useradd -m -s /bin/bash newuser  # 创建新用户newuser，自动创建家目录，登录shell为bash
sudo useradd -g staff -G sudo newuser  # 创建用户newuser，初始组为staff，附加组为sudo（获取管理员权限）

5. passwd - 修改用户密码

功能：修改当前用户或其他用户的密码（修改其他用户需 root 权限）。核心参数：

• -l（lock）：锁定用户（禁止登录）。
• -u（unlock）：解锁用户。
• -d（delete）：删除用户密码（登录无需密码）。

示例：

passwd  # 修改当前用户密码（输入时密码不显示）
sudo passwd newuser  # 管理员修改newuser的密码
sudo passwd -l newuser  # 锁定newuser用户

6. userdel - 删除用户

功能：删除系统用户（需 root 权限）。核心参数：

• -r（remove）：递归删除用户家目录和邮件目录（默认仅删除用户账号）。

示例：

sudo userdel -r newuser  # 彻底删除newuser用户及家目录

7. groupadd/groupdel - 组管理

功能：groupadd创建用户组，groupdel删除用户组（需 root 权限）。

示例：

sudo groupadd dev  # 创建名为dev的用户组
sudo groupdel dev  # 删除dev用户组

8. id/whoami/w - 查看用户信息

• id：显示当前用户的 UID、GID 及所属组。
• whoami：显示当前登录用户名。
• w：显示当前系统所有登录用户及他们的操作。

示例：

id  # 输出如：uid=1000(user) gid=1000(user) groups=1000(user),4(adm),24(cdrom)...
whoami  # 输出当前用户名，如user
w  # 显示所有登录用户及进程信息

三、系统管理与进程命令

1. ps - 查看进程状态

功能：列出当前系统的进程信息。核心参数：

• aux：显示所有用户的所有进程（最常用组合）。
• -ef：显示进程的父进程 ID（PPID）、进程 ID（PID）等详细信息。
• -u 用户名：仅显示指定用户的进程。

示例：

ps aux  # 查看所有进程（USER用户名、PID进程ID、%CPU CPU使用率、%MEM内存使用率、COMMAND命令）
ps aux | grep "nginx"  # 查看nginx相关进程
ps -ef | grep "python"  # 查看python进程及父进程ID

2. top - 实时监控系统资源与进程

功能：实时动态显示系统 CPU、内存、进程等资源使用情况（默认每 3 秒刷新）。交互快捷键：

• P：按 CPU 使用率排序（默认）。
• M：按内存使用率排序。
• N：按进程 ID（PID）排序。
• k：终止指定 PID 的进程。
• q：退出 top。

示例：

top  # 启动实时监控
top -u user  # 仅监控用户user的进程

3. kill - 终止进程

功能：向进程发送信号，实现终止、重启等操作（需知道进程 PID，root 可终止任意进程）。核心信号：

• -15（SIGTERM，默认）：优雅终止进程（允许进程清理资源）。
• -9（SIGKILL）：强制终止进程（立即杀死，无清理，慎用）。
• -1（SIGHUP）：重启进程（部分服务如 nginx、apache 支持）。

示例：

kill 1234  # 向PID为1234的进程发送SIGTERM信号（优雅终止）
kill -9 1234  # 强制终止PID为1234的进程
kill -1 8080  # 重启PID为8080的服务进程
killall nginx  # 终止所有nginx进程（按进程名终止，需安装psmisc包）

4. systemctl - 系统服务管理（Systemd 系统）

功能：管理系统服务（启动、停止、重启、设置开机自启，适用于 Ubuntu 16.04+、CentOS 7+）。核心用法：

systemctl start 服务名    # 启动服务
systemctl stop 服务名     # 停止服务
systemctl restart 服务名  # 重启服务
systemctl status 服务名   # 查看服务状态
systemctl enable 服务名   # 设置开机自启
systemctl disable 服务名  # 取消开机自启
systemctl list-unit-files --type=service  # 列出所有服务及开机自启状态

示例：

sudo systemctl start nginx  # 启动nginx服务
sudo systemctl stop mysql  # 停止mysql服务
sudo systemctl restart sshd  # 重启ssh服务
sudo systemctl status docker  # 查看docker服务状态
sudo systemctl enable nginx  # 设置nginx开机自启

5. df - 查看磁盘空间使用情况

功能：显示文件系统的磁盘空间使用情况（总容量、已用、可用、挂载点）。核心参数：

• -h（human-readable）：人性化显示大小（KB/MB/GB）。
• -T（type）：显示文件系统类型（如 ext4、xfs）。

示例：

df -h  # 查看所有挂载的文件系统磁盘使用情况
df -h /home  # 查看/home目录所在文件系统的磁盘使用情况
df -T  # 显示文件系统类型

6. du - 查看目录 / 文件磁盘占用

功能：计算文件或目录占用的磁盘空间（与df区别：df看文件系统整体，du看具体文件 / 目录）。核心参数：

• -h：人性化显示大小。
• -s（summarize）：仅显示总大小（不显示子目录详情）。
• -c（total）：显示总计大小。

示例：

du -sh /home/user  # 查看/home/user目录总占用空间
du -h /var/log/  # 查看/var/log目录及子目录的占用详情
du -hc *.txt  # 查看所有.txt文件的占用大小，并显示总计

7. free - 查看内存使用情况

功能：显示系统内存（物理内存、交换分区）的使用情况。核心参数：

• -h：人性化显示大小。
• -m：以 MB 为单位显示（默认 KB）。
• -g：以 GB 为单位显示。

示例：

free -h  # 人性化显示内存使用情况
free -m  # 以MB为单位显示

8. uname - 查看系统信息

功能：显示系统内核版本、主机名、硬件架构等信息。核心参数：

• -a（all）：显示所有系统信息（最常用）。
• -r：仅显示内核版本。
• -n：仅显示主机名。

示例：

uname -a  # 输出如：Linux ubuntu 5.4.0-150-generic #167-Ubuntu SMP Wed May 24 15:51:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
uname -r  # 输出内核版本：5.4.0-150-generic

9. hostname - 查看 / 修改主机名

功能：显示或临时修改系统主机名（永久修改需编辑配置文件）。

示例：

hostname  # 显示当前主机名
sudo hostname new-hostname  # 临时修改主机名为new-hostname（重启失效）
sudo hostnamectl set-hostname new-hostname  # 永久修改主机名（Systemd系统，无需重启）

10. date - 查看 / 修改系统时间

功能：显示或修改系统日期和时间。

示例：

date  # 显示当前系统时间（如：Wed Oct 18 15:30:22 CST 2023）
date "+%Y-%m-%d %H:%M:%S"  # 自定义格式显示（年-月-日 时:分:秒）
sudo date -s "2024-01-01 10:00:00"  # 修改系统时间为指定时间

四、网络操作命令

1. ifconfig/ip - 网络接口配置

功能：查看或配置网络接口（IP 地址、子网掩码、MAC 地址等）。

• ifconfig：传统命令（部分系统需安装 net-tools 包）。
• ip：新一代命令（功能更全，推荐使用）。

示例：

ifconfig  # 查看所有网络接口信息
ip addr  # 查看IP地址（等价于ifconfig）
ip link set eth0 up/down  # 启用/禁用eth0网卡
sudo ifconfig eth0 192.168.1.100 netmask 255.255.255.0  # 临时设置eth0的IP地址

2. ping - 测试网络连通性

功能：向目标主机发送 ICMP 请求包，测试网络是否可达。核心参数：

• -c 次数：指定发送包的次数（默认无限发送，Ctrl+C 终止）。
• -i 间隔：指定发送间隔（默认 1 秒）。
• -s 大小：指定数据包大小。

示例：

ping www.baidu.com  # 测试与百度的连通性（无限发送）
ping -c 4 192.168.1.1  # 向网关发送4个数据包测试连通性

3. netstat/ss - 查看网络连接状态

功能：显示系统的网络连接、端口监听、进程关联等信息。

• netstat：传统命令（需安装 net-tools 包）。

• ss：新一代命令（更快、功能更全）。
  核心参数：

• -t（tcp）：仅显示 TCP 连接。

• -u（udp）：仅显示 UDP 连接。

• -l（listen）：仅显示监听状态的端口。

• -n（numeric）：显示 IP 和端口号（不解析域名）。

• -p（program）：显示关联的进程 PID 和名称（需 root 权限）。

示例：

netstat -tlnp  # 查看所有监听的TCP端口及关联进程
ss -ulnp  # 查看所有监听的UDP端口及关联进程
netstat -an | grep 80  # 查看80端口的连接状态

4. curl/wget - 网络下载工具

• curl：多功能网络工具，支持 HTTP/HTTPS/FTP 等协议，可下载文件、发送请求。
• wget：专注于文件下载（支持断点续传、后台下载）。

示例：

# curl用法
curl https://www.baidu.com  # 访问百度并输出HTML内容
curl -O https://example.com/file.zip  # 下载文件并保存为原文件名
curl -L https://example.com/redirect  # 跟随重定向下载

# wget用法
wget https://example.com/file.zip  # 下载文件
wget -c https://example.com/large.zip  # 断点续传下载大文件
wget -b https://example.com/bigfile.iso  # 后台下载（日志保存到wget-log）

5. scp - 远程文件复制

功能：通过 SSH 协议在本地和远程主机之间复制文件 / 目录（加密传输）。核心参数：

• -r：递归复制目录。
• -P 端口：指定远程主机 SSH 端口（默认 22）。

示例：

# 本地文件复制到远程主机
scp localfile.txt user@remote-ip:/home/user/

# 远程文件复制到本地
scp user@remote-ip:/home/user/remotefile.txt ./

# 复制目录（加-r）
scp -r localdir/ user@remote-ip:/home/user/

6. ssh - 远程登录

功能：通过 SSH 协议远程登录 Linux 主机（加密传输，安全）。核心参数：

• -p 端口：指定远程主机 SSH 端口（默认 22）。
• -X：启用 X11 转发（远程图形界面）。

示例：

ssh user@remote-ip  # 登录远程主机（默认端口22）
ssh -p 2222 user@remote-ip  # 登录指定端口2222的远程主机
ssh -X user@remote-ip  # 登录并启用图形界面转发

五、压缩与解压命令

1. tar - 归档 / 压缩工具（最常用）

功能：将多个文件 / 目录归档为一个 tar 包，可结合 gzip/bzip2/xz 压缩。核心参数（记忆口诀：打包压缩czf，解压xzf）：

• -c（create）：创建归档包。
• -x（extract）：解压归档包。
• -z（gzip）：用 gzip 压缩 / 解压（后缀.tar.gz或.tgz）。
• -j（bzip2）：用 bzip2 压缩 / 解压（后缀.tar.bz2）。
• -J（xz）：用 xz 压缩 / 解压（后缀.tar.xz）。
• -f（file）：指定归档文件名（必须放在参数最后）。
• -v（verbose）：显示压缩 / 解压过程。
• -C（directory）：指定解压目录（默认当前目录）。

示例：

# 压缩（tar.gz格式）
tar -czvf file.tar.gz dir1/ file1.txt  # 将dir1和file1.txt压缩为file.tar.gz

# 解压（tar.gz格式）
tar -xzvf file.tar.gz  # 解压到当前目录
tar -xzvf file.tar.gz -C /home/user/  # 解压到/home/user目录

# 压缩（tar.bz2格式）
tar -cjvf file.tar.bz2 dir1/

# 解压（tar.xz格式）
tar -xJvf file.tar.xz

2. zip/unzip - ZIP 格式压缩 / 解压

功能：处理 ZIP 格式的压缩文件（跨平台兼容，Windows/Linux 通用）。

示例：

# 压缩（需安装zip包）
zip -r file.zip dir1/ file1.txt  # 递归压缩dir1和file1.txt为file.zip

# 解压（需安装unzip包）
unzip file.zip  # 解压到当前目录
unzip file.zip -d /home/user/  # 解压到指定目录
unzip -l file.zip  # 查看压缩包内的文件列表

3. gzip/gunzip - GZ 格式压缩 / 解压

功能：压缩单个文件（不能压缩目录），压缩后原文件删除（后缀.gz）。

示例：

gzip file.txt  # 压缩file.txt为file.txt.gz（原文件删除）
gzip -k file.txt  # 压缩并保留原文件
gunzip file.txt.gz  # 解压为file.txt（原.gz文件删除）

六、其他实用命令

1. history - 查看命令历史

功能：显示当前用户执行过的命令历史（默认保存 1000 条，可通过HISTSIZE调整）。

示例：

history  # 查看所有命令历史
history 10  # 查看最近10条命令
!123  # 执行历史中第123条命令
!ls  # 执行上一条以ls开头的命令
Ctrl+R  # 搜索命令历史（输入关键词匹配）

2. alias - 设置命令别名

功能：为常用命令设置简化别名（临时生效，永久生效需写入配置文件）。

示例：

alias ll='ls -lha'  # 临时设置ll为ls -lha的别名
alias rm='rm -i'  # 临时设置rm为带提示的删除（安全）

# 永久生效（写入用户配置文件）
echo "alias ll='ls -lha'" >> ~/.bashrc  # 对当前用户生效
source ~/.bashrc  # 立即生效（无需重启终端）

unalias ll  # 取消别名

3. sudo - 临时获取 root 权限

功能：允许普通用户执行需 root 权限的命令（需在/etc/sudoers中配置权限）。

示例：

sudo apt update  # 以root权限更新软件源（Debian/Ubuntu）
sudo yum install nginx  # 以root权限安装nginx（CentOS/RHEL）
sudo -i  # 切换到root用户（需输入当前用户密码）

4. apt/yum/dnf - 包管理命令

功能：Linux 系统软件包管理工具（自动解决依赖关系）。

• apt：Debian/Ubuntu 系列系统（apt-get的简化版）。
• yum：CentOS 6/RHEL 6 系列（已逐步被 dnf 替代）。
• dnf：CentOS 7+/RHEL 7 + 系列（yum 的升级版）。

示例：

# Debian/Ubuntu（apt）
sudo apt update  # 更新软件源索引
sudo apt install nginx  # 安装nginx
sudo apt remove nginx  # 卸载nginx（保留配置文件）
sudo apt purge nginx  # 彻底卸载nginx（删除配置文件）
sudo apt upgrade  # 升级所有已安装软件

# CentOS/RHEL（yum）
sudo yum update  # 更新软件源
sudo yum install nginx  # 安装nginx
sudo yum remove nginx  # 卸载nginx
sudo yum list installed  # 列出已安装软件

# CentOS 8+/RHEL 8+（dnf）
sudo dnf install nginx
sudo dnf remove nginx

5. echo - 输出字符串 / 变量

功能：在终端输出指定字符串或环境变量的值。

示例：

echo "Hello Linux"  # 输出字符串
echo $PATH  # 输出环境变量PATH的值（系统命令搜索路径）
echo "当前用户：$USER"  # 输出当前用户名（变量需加$）
echo "abc" > file.txt  # 将字符串写入文件（覆盖原有内容）
echo "def" >> file.txt  # 将字符串追加到文件末尾

6. wc - 统计文本行数 / 字数 / 字节数

功能：统计文件或命令输出的行数（-l）、单词数（-w）、字节数（-c）。

示例：

wc -l file.txt  # 统计file.txt的行数
wc -w file.txt  # 统计单词数
wc -c file.txt  # 统计字节数
cat file.txt | wc -l  # 统计命令输出的行数

七、命令行实用技巧

1. 管道符 |：将前一个命令的输出作为后一个命令的输入

   ps aux | grep nginx # 筛选nginx进程

2. 重定向

   • 覆盖写入文件

     ls > list.txt

   • 追加写入文件

     echo "test" >> list.txt

   • 从文件读取输入

     wc -l < file.txt

1. 通配符

   • *：匹配任意多个字符（如*.txt所有.txt 文件）
   • ?：匹配单个字符（如file?.txt匹配 file1.txt、file2.txt）
   • []：匹配括号内的任意一个字符（如file[1-3].txt匹配 file1-3.txt）

2. 快捷键

   • Tab：自动补全命令 / 文件名 / 目录名（高效必备）
   • Ctrl+C：终止当前运行的命令
   • Ctrl+D：退出当前终端 / 登录会话（等价于 exit）
   • Ctrl+Z：暂停当前命令（用fg恢复到前台，bg放到后台）

1. 数据
2. 信息
3. 数据处理

数据库管理技术的发展阶段

1. 人工管理
2. 文件系统
3. 数据库系统
4. 大数据

数据库系统的组成

1. 硬件系统
2. 操作系统
3. .数据库
4. 数据库管理系统
5. 数据库应用系统的开发工具及相关接口软件
6. 数据库应用系统
7. 用户
   1. 数据库管理员
   2. 数据库分析师
   3. 应用程序员
   4. 终端用户

数据库体系结构

1. 集中式系统
2. 分布式系统
3. 个人计算机系统
4. 客户/服务器系统
5. 浏览器/服务器系统

数据库的三级模式

1. 内模式
2. 模式
3. 外模式

数据库的二级映像

1. 外模式/模式
2. 模式/内模式

数据库管理系统的功能

1. 数据定义
2. 数据操控
3. 数据库运行控制
4. 数据字典

登录方式

1. windows登录，本地登录
2. sqlserver登录，远程登录

数据库备份

mdf数据文件，ldf日志文件

1. 分离->附加 分离后数据库会不可用
2. 备份->还原 保存为.bak文件 任务——>备份
3. 数据库脚本

注释

单行注释 —
多行注释 / /

数据库相关

创建数据库

完整语法

create database DBTEST
on --数据文件
(
  name = 'DBTEST', --逻辑名称
  filename = '',  --物理路径和名称 以.mdf结尾
  size = 5MB,--文件的初始大小
  maxsize = 40MB，  --文件的最大大小
  filegrowth=2MB,  --文件增长方式 可以是大小，也可以是百分比
)
log on --日志文件
(
  name = 'DBTEST_log', --逻辑名称
  filename = '',  --物理路径和名称 以.ldf结尾
  size = 5MB,--文件的初始大小
  filegrowth=2MB,  --文件增长方式 可以是大小，也可以是百分比
)

简单语法

create database DBTEST  --采用默认值创建 

修改数据库

alter database DNTEST

删除数据库

drop database 数据库名称

切换数据库

use DBTEST --use 数据库名称

表相关

创建表基础语法

create table 表名
(
 字段1 数据类型，
 字段2 数据类型，
 字段3 数据类型，
) 

约束

• primary key:主建
• references 表名(字段名)：外键
• identify(1,1):自动增长，初始值1，增长步长1
• not null：不为空
• check():检查约束
• default()：默认值
• unique：唯一约束

数据类型

• int:整型
• float:浮点型
• decimal(n,m):n表示总长度，m表示小数位数
• date:年月日 —getdate() 获取当前时间
• datetime：年月日时分秒
• smalldatetime：范围更小
• char():定长字符串
• varchar():变长字符串
• text:长文本
• nchar,nvarchar,ntext:unicode字符,对中文友好

删除表

drop table 表名

修改表结构

1.添加列

alter table 表名 add 新列名 数据类型

2.删除列

alter table 表名 drop column 列名

3.修改列 —如果已经存在数据了则可能报错，建议建表的时候就有冗余

alter table 表名 alter column 列名 数据类型

维护约束

1.删除约束

alter table 表名 drop constraint 约束名

2.添加约束

check约束

alter table 表名 add constraint 约束名 check(表达式)

主键约束

alter table 表名 add constraint 约束名 primary key(列名)

唯一约束

alter table 表名 add constraint 约束名 unique(列名)

默认值约束

alter table 表名 add constraint 约束名 default 默认值 for 列名

外键约束

alter table 表名 add constraint 约束名 foreign key(列名)references 关联表名(列名)

数据相关

插入数据

insert into 表名(字段1,字段2,字段3)values(内容1,内容2,内容3)

简写 —不建议

insert into 表名 values(内容1,内容2,内容3)

一次性插入多行数据

insert into 表名(字段1,字段2,字段3)
select 内容1,内容2,内容3 union
select 内容1,内容2,内容3 union
select 内容1,内容2,内容3

修改删除数据

1.修改

update 表名 set 字段1=值1,字段2=值2 where 条件

2.删除数据

delete from 表名 where 条件

关于删除

drop table 表名  --删除表对象

truncate table 表名  --删除数据(清空数据)，表对象即表结构依然存在，不能有条件，自动编号存在

delete from 表名  --删除数据(清空数据)，表对象即表结构依然存在，可以有条件，自动编号清除

查询相关

基本查询

1.查询所有列所有行

select * from 表名

2.查询指定列

select 列名1,列名2,列名3 from 表名

3.查询指定列,别名显示

select 列名1 别名1,列名2 别名2,列名3 别名3 from 表名

4.查询指定列,去重

select distinct(列名) from 表名

条件查询

select * from 表名 where 条件
select top 10 * from 表名 where 条件  --前十位
select top 10 percent * from 表名 where 条件  --前百分之十
select * from 表名 where order by 字段 desc/asc

模糊查询

• like
• %：代表匹配0个字符，一个字符或多个字符
• _:代表匹配有且只有一个字符
• []:代表匹配范围内
• ！[]:代表匹配不在范围内
• substring(n,m,t) —n为字符串，m是起始位，t是跨度

聚合函数

• count:求数量
• max:求最大值
• min:求最小值
• sum: 求和
• avg:求平均值
• round:保留小数位 round(2.556,2) ——>2.55
• datediff:求时间差 datediff(year,时间1,时间2)

分组查询

select * from 表名 where 条件 group by 列名 having 条件

—普通条件在where后，聚合条件在 having后
注：分组查询只允许查询分组条件和聚合函数

多表查询

select * from 表名1,表名2 where 条件

1.内连接

select * from 表名1 inner join 表名2 on 条件

2.外连接

select * from 表名1 left join 表名2 on 条件  --左外
select * from 表名1 right join 表名2 on 条件  --右外
select * from 表名1 full join 表名2 on 条件  --全外

3.自连接

select 别名1.字段,别名2.字段 from 表名 别名1 inner join 表名 别名2 on 条件

数据库设计

1.三范式

• 第一范式：原子性 不可再分
• 第二范式：实体唯一性
• 第三范式：不能有冗余

2.表关系

• 一对一
• 一对多
• 多对多

变量

—信息打印：

print'hello,sql'      --消息窗口显示

select'hello,sql'     --信息窗口显示

—变量：

1. 局部变量：以@开头，先声明，在赋值

   declare @str varchar(20) set @str='i like sql' --赋值变量指定的值 select @str ='i like sql' --一般用于表中的查询出的数据赋值给变量，如果查询结果有多条，取最后一条赋值

2. 全局变量：以@@开头，由系统就行定义和维护

—go语句:

1. 等待go语句之前的代码执行完之后才能执行后面的代码
2. 批处理结束的一个标志

运算符

强制类型转化

1. Convert(数据类型，变量名) 例：Convert(varchar(10)，@zc)
2. cast(变量名 as 数据类型) 例：cast(@zc as varchar(10))

流程控制语句

(1)选择分支

case选择：

case 
when 条件 then 执行1
when 条件 then 执行2
else 最终执行
end

if判断语句：

if 条件判断
   begin
 语句
   end
else
   begin
     语句
   end

(2)循环

while 条件
begin
  语句
end

子查询

   where条件
临时表
exist

分页

(1)top方案

declare @PageSize int = 5
declare @PageIndex int = 3
select top(@PageSize)*from Student
where StuId not in (select top(@PageSize*(PageIndex-1))StuId from Student)

(2)使用row_number分页

declare @PageSize int = 5
declare @PageIndex int = 3
select *from
(select ROW_NUMBER() over(order by StuId) RowId,*from Student) Temp
where RowId between (@PageIndex-1)*@PageSize+1 and @PageIndex*@PageSize

事务

begin transaction   --开始语句
语句
@@ERROR             --统计错误 如果出现错误 @@ERROR的值不为零

commit transaction     --提交事务
rollback transaction   --回滚事务

索引

1. 聚集索引 —类似于按照拼音查找 只能有一个
2. 非聚集索引 —类似于按照部首查询 可以有多个

添加索引

create [unique][clustered|nonclustered] index <index name> on <table or view name>(<colum name>[ASC|DESC][,...n])

查看索引 （sys.indexes）

select * from sys.indexes where name = '索引名'

删除索引

drop index 索引名 on 表名

使用索引

select * from 表名 with (index=索引名) where 条件

视图

创建视图：

create view 视图名 as select语句 go

查询视图：

select * from 视图名

删除视图：

drop view 视图名

游标

分类：

• 静态游标
• 动态游标
• 键集驱动游标

创建游标(scroll：滚动游标，没有scroll，只进)

declare 游标名 cursor scroll for select 字段名 from 表名

打开游标

open 游标名

关闭游标

close 游标名

删除游标

deallocate 游标名

提取数据

fetch first from 游标名         --提取第一行
fetch last from 游标名   --提取最后一行
fetch absolute 2 from 游标名    --提取第二行
fetch relative 2 from 游标名    --当前行下移两行
fetch next from 游标名     --下移一行
fetch prior from 游标名    --上移一行

—提取游标数据存放入变量，进行查询所有列信息

declare @acc varchar(20)
fetch absolute 2 from mycur into @acc
select * from Menber where MenberAccount=@acc

—遍历游标

  @@fetch_status  ：0提取成功，-1提取失败，-2不存在
declare @acc varchar(20)
fetch absolute 2 from mycur into @acc
while @@fetch_status=0
begin
print'提取成功：'+@acc
fetch next from mycur into @acc
end

—利用游标进行数据的修改和删除

fetch absolute 2 from mycur
update Member set MemberPwd = '654321' where current of mycur

fetch absolute 2 from mycur
delete from Member where current of mycur

—一行多列游标

declare 游标名 cursor scroll for select 字段1，字段2，字段3 from 表名

函数

1. 系统函数
2. 自定义函数
   1. 标量值函数（返回单个值）
   2. 表值函数（返回查询结果）

创建函数

create function 函数名(@传入值 传入值类型) returns 返回值类型
as 
begin
declare @返回值 返回值类型
select @返回值 = 
return @返回值
end

返回值类型的情况

1. 可以有其他逻辑代码

   create function 函数名(@传入值 传入值类型) returns @返回值 table ( 字段1 数据类型， 字段2 数据类型， 字段3 数据类型， 字段4 数据类型 ) as begin insert into @返回值 查询语句 return end

2. 函数体只能有return+sql查询结果

   create function 函数名(@传入值 传入值类型) returns table as return 查询语句 go

   函数调用

   select dbo.函数名() --返回值为一个值 select * from 函数名() --返回值为一个表

函数删除

drop function 函数名

触发器

分类

1. instead of 事前触发器
2. after 事后触发器

创建触发器

create trigger 触发器名称 on 表名 [after|instead of] [insert|delete|update]
as 
语句
go

   inserted插入的临时表
   deleted删除的临时表

数据更新实际上是先删除再插入

存储过程

存储过程与函数的主要区别：存储过程可以被其他程序调用，函数一般用于select语句中

创建存储过程

存储过程创建

create proc 存储过程名 @变量1名 变量类型，@变量2名 变量类型，@变量3名 变量类型 output，@变量4名 变量类型 output
as
语句
go

存储过程的调用

exec 存储过程名 变量值1，变量值2，变量名 output，变量名 output   --前两个用于输入，后两个用于接收，如果变量名(第三四个)已经赋值了则具有输入输出功能

删除存储过程

drop proc 存储过程名

error: failed to push some refs to 'http://xxxx.cn/vip/xxx.git'
To http://xxxx.cn/vip/xxx.git
!refs/heads/master:refs/heads/master[rejected] (fetch first)
Done
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.

或简化版错误：

[rejected]   master -> master (fetch first)    
error: failed to push some refs

这是 Git 常见的版本冲突问题，原因是远程仓库存在本地没有的更新，为防止覆盖远程变更而拒绝推送。

推荐解决方案

最简洁高效的处理方式是执行以下命令：

# 拉取远程master分支并以rebase方式整合本地更改
git pull --rebase origin master

# 完成整合后再次推送（-u参数会建立本地与远程分支的关联）
git push -u origin master

1. 将远程最新更改下载到本地
2. 以线性方式重新应用你的本地提交
3. 建立本地与远程分支的关联关系

备选解决方案（适用于复杂冲突）

如果遇到复杂的代码冲突，可使用标准合并流程：

# 拉取远程更新并合并到本地
git pull origin master

# 若出现冲突，编辑冲突文件后标记为已解决
git add <冲突的文件路径>

# 提交合并结果
git commit -m "合并远程更新并解决冲突"

# 推送本地更改
git push origin master

注意事项

• git pull --rebase 会改写提交历史，保持提交记录更整洁
• 多人协作时，推送前先拉取是良好习惯
• 解决冲突时需仔细检查代码，确保逻辑正确
• 首次推送分支时，-u 参数只需使用一次，后续可直接用 git push
  以上方法可解决绝大多数推送失败问题，推荐优先使用 git pull --rebase 方式，它能更优雅地处理分支同步问题。

参考正则表达式 – 教程 | 菜鸟教程

1.什么是正则表达式？

正则表达式（Regular Expression，简称 Regex 或 RegExp）是一种用来匹配字符串中字符组合的模式。

简单来说就是一种匹配内容的模板。

2.正则表达式的作用

• 查找： 在文本中找到特定模式的内容
• 替换： 将符合某种模式的文本替换为其他内容
• 验证： 检查输入的数据是否符合预期格式
• 提取： 从复杂文本中提取需要的信息

3.正则表达式的模式

• 字面值字符：例如字母、数字、空格等，可以直接匹配它们自身。
• 特殊字符：例如点号 .、星号 *、加号 +、问号 ? 等，它们具有特殊的含义和功能。
• 字符类：用方括号 [ ] 包围的字符集合，用于匹配方括号内的任意一个字符。
• 元字符：例如 \d、\w、\s 等，用于匹配特定类型的字符，如数字、字母、空白字符等。
• 量词：例如 {n}、{n,}、{n,m} 等，用于指定匹配的次数或范围。
• 边界符号：例如 ^、$、\b、\B 等，用于匹配字符串的开头、结尾或单词边界位置。

4.正则表达式元字符和特性

字符匹配

• 普通字符：普通字符按照字面意义进行匹配，例如匹配字母 “a” 将匹配到文本中的 “a” 字符。
• 元字符：元字符具有特殊的含义，例如 \d 匹配任意数字字符，\w 匹配任意字母数字字符，. 匹配任意字符（除了换行符）等。

基本元字符

. (点号)

• 匹配除换行符(\n)外的任意单个字符

  示例：a.b 匹配 “aab”, “a1b”, “a b” 等

^ (脱字符)

• 匹配字符串的开始位置
• 示例：^abc 匹配以 “abc” 开头的字符串

$ (美元符)

• 匹配字符串的结束位置
• 示例：xyz$ 匹配以 “xyz” 结尾的字符串

\ (反斜杠)

• 转义字符，使后面的字符失去特殊含义
• 示例：\. 匹配实际的点号而不是任意字符

量词

• *：匹配前面的模式零次或多次。
• +：匹配前面的模式一次或多次。
• ?：匹配前面的模式零次或一次。
• {n}：匹配前面的模式恰好 n 次。
• {n,}：匹配前面的模式至少 n 次。
• {n,m}：匹配前面的模式至少 n 次且不超过 m 次。

字符类

• [ ]：匹配括号内的任意一个字符。例如，[abc] 匹配字符 “a”、”b” 或 “c”。
• [^ ]：匹配除了括号内的字符以外的任意一个字符。例如，[^abc] 匹配除了字符 “a”、”b” 或 “c” 以外的任意字符。
• [A-Z]：表示一个区间，匹配所有大写字母，[a-z] 表示所有小写字母。

边界匹配

• ^：匹配字符串的开头。
• $：匹配字符串的结尾。
• \b：匹配单词边界。
• \B：匹配非单词边界。

分组和选择元字符

() (圆括号)

• 定义子表达式或捕获组
• 示例：(ab)+ 匹配 “ab”, “abab” 等

| (竖线)

• 表示”或”关系
• 示例：cat|dog 匹配 “cat” 或 “dog”

特殊字符

\d

• 匹配任意数字，等价于 [0-9]

\D

• 匹配任意非数字，等价于 [^0-9]

\w

• 匹配任意单词字符(字母、数字、下划线)，等价于 [a-zA-Z0-9_]

\W

• 匹配任意非单词字符，等价于 [^a-zA-Z0-9_]

\s

• 匹配任意空白字符(空格、制表符、换行符等)

\S

• 匹配任意非空白字符

非打印符

5.常用修饰符

1. i (ignore case) - 忽略大小写

• 使匹配不区分大小写
• 示例：/abc/i 可以匹配 “abc”, “Abc”, “ABC” 等
• 支持语言：几乎所有正则表达式实现（JavaScript、PHP、Python等）

2. g (global) - 全局匹配

• 查找所有匹配项，而不是在第一个匹配后停止
• 示例：在字符串 “ababab” 中，/ab/g 会匹配所有三个 “ab”
• 支持语言：JavaScript、PHP等

3. m (multiline) - 多行模式

• 改变 ^ 和 $ 的行为，使其匹配每行的开头和结尾，而不仅是整个字符串的开头和结尾
• 示例：在多行字符串中，/^abc/m 会匹配每行开头的 “abc”
• 支持语言：JavaScript、PHP、Python、Perl等

4. s (single line/dotall) - 单行模式

• 使点号 . 匹配包括换行符在内的所有字符
• 在JavaScript中称为”dotall”模式，使用 /s 修饰符
• 示例：/a.b/s 可以匹配 “a\nb”
• 支持语言：PHP、Perl、Python(作为re.DOTALL)、JavaScript(ES2018+)

5. u (unicode) - Unicode模式

• 启用完整的Unicode支持
• 正确处理UTF-16代理对和Unicode字符属性
• 示例：/\p{Script=Greek}/u 可以匹配希腊字母
• 支持语言：JavaScript、PHP等

6. y (sticky) - 粘性匹配

• 从目标字符串的当前位置开始匹配（使用lastIndex属性）
• 类似于^锚点，但针对的是匹配的起始位置
• 示例：在JavaScript中，/a/y 会从lastIndex开始匹配 “a”
• 支持语言：JavaScript

7. x (extended) - 扩展模式

• 忽略模式中的空白和注释，使正则表达式更易读
• 示例：在PHP中，/a b c/x 等同于 /abc/
• 支持语言：PHP、Perl、Python(作为re.VERBOSE)

6.贪婪与非贪婪量词

默认情况下，量词(*, +, ?, {})是贪婪的，会尽可能多地匹配字符。在量词后加?可使其变为非贪婪(懒惰)模式：

• *?：零次或多次，但尽可能少
• +?：一次或多次，但尽可能少
• ??：零次或一次，但尽可能少
• {n,m}?：n到m次，但尽可能少

示例：<.*?> 匹配HTML标签时不会跨标签匹配

7.断言

断言（Assertion）是正则表达式中用于指定匹配位置的元字符，它们不匹配任何实际字符，而是匹配字符之间的位置。

简单来说，断言就是”条件”，它要求目标字符串必须满足某些条件，但不会消耗字符。

断言的特点

1. 零宽度：不占用匹配字符的位置
2. 条件检查：只检查是否满足特定条件
3. 不影响匹配结果：仅作为匹配的约束条件

断言类型

(?=...) (正向肯定预查)

• 匹配后面跟着特定模式的位置
• 示例：Windows(?=95|98) 匹配后面跟着95或98的”Windows”

(?!...) (正向否定预查)

• 匹配后面不跟着特定模式的位置
• 示例：Windows(?!95|98) 匹配后面不跟着95或98的”Windows”

(?<=...) (反向肯定预查)

• 匹配前面是特定模式的位置
• 示例：(?<=95|98)Windows 匹配前面是95或98的”Windows”

(?<!...) (反向否定预查)

• 匹配前面不是特定模式的位置
• 示例：(?<!95|98)Windows 匹配前面不是95或98的”Windows”

8.运算符优先级

以下是一些常见正则表达式运算符按照优先级从高到低的顺序：

• 转义符号： \ 是用于转义其他特殊字符的转义符号。它具有最高的优先级。

  示例：\d、\. 等，其中 \d 匹配数字，\. 匹配点号。

• 括号： 圆括号 () 用于创建子表达式，具有高于其他运算符的优先级。

  示例：(abc)+ 匹配 “abc” 一次或多次。

• 量词： 量词指定前面的元素可以重复的次数。

  示例：a* 匹配零个或多个 “a”。

• 字符类： 字符类使用方括号 [] 表示，用于匹配括号内的任意字符。

  示例：[aeiou] 匹配任何一个元音字母。

• 断言： 断言是用于检查字符串中特定位置的条件的元素。

  示例：^ 表示行的开头，$ 表示行的结尾。

• 连接： 连接在没有其他运算符的情况下表示字符之间的简单连接。

  示例：abc 匹配 “abc”。

• 管道： 管道符号 | 表示”或”关系，用于在多个模式之间选择一个。

  示例：cat|dog 匹配 “cat” 或 “dog”。

9.分组和引用