Netlify将url重定向到小写问题
hexo版本5.0.2 npm版本6.14.7 next版本7.8.0
前两天将博客从vercel改为托管到Netlify上，本来运行的挺流畅的。但是今天我看一篇博客的评论时突然发现，虽然有评论
但是文章开头的评论数显示的是0
这里的评论系统使用的是Valine
我记得之前是好的，怎么突然不好使了呢。
DHCP协议
DHCP 协议：动态主机配置的自动化解决方案
DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）是应用层的核心协议之一，它通过自动化分配 IP 地址及相关网络参数，实现了设备的 “即插即用” 联网，极大简化了网络配置流程。无论是家庭 WiFi、企业局域网还是大型数据中心，DHCP 都是保障设备高效接入网络的关键技术。
DHCP 协议的核心功能
DHCP 的核心价值在于动态分配网络参数，无需用户手动配置，具体包括：
- 分配 IPv4 地址（如
192.168.1.100）； - 分配子网掩码（如
255.255.255.0），用于区分网络地址和主机地址； - 指定默认网关 IP（如
192.168.1.1），实现跨网段通信； - 提供 DNS 服务器地址（如
8.8.8.8），支持域名解析； - 其他可选参数（如 IP 地址租用期限、NTP 服务器地址等）。
通过这些参数，设备能自动完成网络初始化，快速接入网络并与其他设备通信。
DHCP 的工作过程：四步握手实现动态配置
DHCP 的工作过程本质是客户端与服务器之间的 “请求 - 分配” 交互，通过四个关键报文完成配置，具体流程如下：
1. 客户端发送 Discover 报文（发现服务器）
- 触发场景：客户端（如手机、电脑）接入网络后，若未配置 IP 地址，会自动发起 DHCP 请求。
- 报文细节：
- 源地址：
0.0.0.0:68（客户端尚未获取 IP，使用无效地址）； - 目的地址：
255.255.255.255:67（广播地址，DHCP 服务器默认端口为 67）； - 封装协议：基于 UDP 传输，报文包含客户端的 MAC 地址（用于服务器识别设备）。
- 源地址：
- 作用：客户端广播请求，寻找网络中可用的 DHCP 服务器。
电子邮件协议
电子邮件协议：从发送到接收的完整流程解析
电子邮件系统是互联网最基础的应用之一，其高效运行依赖于一系列标准化协议。一个完整的电子邮件系统由用户代理（如 Outlook、 Gmail 客户端）、邮件服务器（负责存储和转发邮件）和邮件协议（规范数据传输格式与流程）三部分构成。其中，邮件协议又分为发送协议（如 SMTP）和读取协议（如 POP3、IMAP），它们共同保障了邮件的可靠传输与灵活访问。
SMTP 协议：邮件发送的核心规范
SMTP（Simple Mail Transfer Protocol，简单邮件传输协议）是电子邮件发送的基础协议，定义了邮件从客户端发送到邮件服务器，以及从源邮件服务器转发到目标邮件服务器的规则。
核心功能与限制
- 基本功能：负责将邮件从发送方服务器传递到接收方服务器，支持文本邮件的传输。
- 原生限制：SMTP 最初设计仅只能只能 ASCII 码数据，无法直接发送二进制文件（如图片、附件、非英文字符）。
MIME：突破 SMTP 的传输限制
为解决 SMTP 无法传输二进制数据的问题，MIME（多用途互联网邮件扩展） 应运而生：
分布式表连接问题
密码错误重试导致数据库超慢
数据库密码错误引发连接风暴：Druid 配置防护与故障排查
数据库连接是应用的核心依赖，一旦密码配置错误，可能引发连锁反应：连接池持续重试、数据库连接耗尽、应用响应超时。本文将深入分析密码错误导致的连接风暴原理，详解如何通过 Druid 配置防护，并提供故障排查与应急处理方案，帮助你避免类似问题。
密码错误引发连接风暴的原理
问题现象
当数据库密码配置错误时，应用会出现以下症状：
- 页面加载缓慢（十几秒甚至超时）；
- 数据库
show full processlist显示大量Connect状态的连接（来自应用服务器 IP）； - 应用日志频繁出现
Access denied for user 'xxx'@'xxx' (using password: YES)错误； - 连接池
activeCount持续飙升，最终达到maxActive上限。
底层原因分析
密码错误触发了连接池的无限重试机制，形成恶性循环：
- 初始连接失败：应用启动或首次获取连接时，因密码错误被数据库拒绝，抛出认证异常；
- 连接池重试：默认配置下，Druid 会重试连接（默认重试 1 次），若仍失败，会不断尝试创建新连接；
- 数据库连接堆积：每次重试都会向数据库发起
Connect请求，即使认证失败，数据库仍需消耗资源处理请求，导致连接队列拥堵； - 连接池耗尽：大量失败的连接请求占用连接池资源，正常请求无法获取连接，形成 “雪崩效应”。
为何影响其他项目？
若多个项目共享同一数据库，一个项目的密码错误重试会占用数据库的连接资源（如 MySQL 默认 max_connections=151），导致其他项目的正常连接请求被阻塞，出现 “一损俱损” 的连锁反应。
Druid 关键配置：限制重试与熔断
Druid 提供了连接错误重试和熔断配置，可有效避免密码错误引发的连接风暴。核心配置包括：
连接错误重试次数（connectionErrorRetryAttempts）
- 作用：设置连接失败后的最大重试次数，超过次数后停止重试；
- 默认值：1（仅重试 1 次）；
- 最佳实践：建议设为
0-2（减少无效重试）。