安装以及使用​

# 安装
go install github.com/mailhog/MailHog@latest

# 使用
MailHog

然后访问浏览器地址：http://0.0.0.0:8025/

邮件发送端口是：1025

更多请参考：文档

测试发送邮件​

# 安装发送邮件服务
go install github.com/mailhog/mhsendmail@latest
# 发送测试邮件
mhsendmail test@mailhog.local <<EOF
From: App <app@mailhog.local>
To: Test <test@mailhog.local>
Subject: Test message

Some content!
EOF

更多请参考：文档

安装​

Debian/Ubuntu (apt) amd64

sudo apt update -y && sudo apt install -y curl
sudo install -dm 755 /etc/apt/keyrings
curl -fSs https://mise.jdx.dev/gpg-key.pub | sudo tee /etc/apt/keyrings/mise-archive-keyring.pub 1> /dev/null
echo "deb [signed-by=/etc/apt/keyrings/mise-archive-keyring.pub arch=amd64] https://mise.jdx.dev/deb stable main" | sudo tee /etc/apt/sources.list.d/mise.list
sudo apt update
sudo apt install -y mise

使用​

# 安装并设置全局生效
mise use -g go

# 安装并设置当前目录生效
mise use go

更多请参考：官方文档

优点​

日历化版本 (CalVer) 通过将版本号与时间绑定，实现了 "版本即时间，时间即价值" 的理念。它超越了传统版本号的简单标识功能，成为团队协作的时间轴、用户决策的参考点和产品生命周期的管理工具，特别适合当今快速迭代的软件开发环境。

若你的项目追求透明性、可预测性和高效协作，CalVer 值得认真考虑。

直观易懂，一见即知​

版本号直接反映发布时间 (如2024.10表示 2024 年 10 月)，无需文档解释 普通人也能立即判断版本新旧，无需理解复杂的数字规则 特别适合面向终端用户的产品，提升用户体验

规划透明，协作增效​

团队和用户可通过版本号直接掌握发布节奏 (如24.4.0表示 Q2 发布) 使软件发布与业务时间表 (如财季、促销节点) 无缝对齐 便于客户预期管理：可根据月份预判版本包含的季度功能 减少沟通成本，使跨团队协作更高效

时间维度，价值倍增​

历史追溯：一眼定位版本发布时间，便于问题排查和审计 维护状态判断：开发者评估依赖库时，版本号直接反映维护活跃度 生命周期管理：可实现 "日期驱动的弃用策略"，明确版本支持期限 例如：Ubuntu 的20.04版本明确提供 5 年支持，用户可据此规划升级

技术优势，开发利器​

冲突自动规避：时间戳天然唯一，避免并行开发的版本号冲突 排序简便：版本号按时间自然排序，无需额外算法 自动化友好：构建脚本可轻松实现版本号自动生成，减少人工错误 特别适合高频发布场景 (如 Web 应用、SaaS 平台)，大幅提升交付效率

生态适配，降低成本​

减少版本管理的认知负担，尤其适合大型团队和复杂项目 与持续集成 / 持续部署 (CI/CD) 管道完美集成，加速交付周期 可与语义化版本结合，形成混合方案 (如YYYY.MINOR.PATCH)，兼顾时间与功能 对开源项目特别有益：贡献者和用户能快速评估项目活跃度

适用场景​

缺点​

功能与兼容性信息缺失（最致命缺点）​

CalVer 完全抛弃了版本号对 “功能变更类型” 的语义标识，而这恰恰是软件协作和依赖管理的关键：

• 无法判断升级风险：用户无法从版本号（如 2024.10 → 2024.11）中得知是否包含破坏性变更（比如 API 删除、参数修改）、新增功能还是仅修复 bug—— 这对依赖该项目的开发者来说是致命的，可能导致 “无意识升级” 引发生产环境故障。
• 功能增量不透明：即使两个版本间隔 1 个月，也无法判断是 “小修小补” 还是 “重大重构”。例如：2024.9 可能仅修复 1 个 bug，2024.10 却重写了核心模块，但版本号无法体现这种差异。
• 对比 SemVer 的劣势：语义化版本（SemVer）通过 MAJOR.MINOR.PATCH 明确区分 “不兼容变更 / 新功能 /bug 修复”，而 CalVer 必须依赖 Release Notes 才能获取这些信息，大幅增加了沟通和验证成本。

版本号粒度混乱，缺乏统一标准​

CalVer 没有强制统一的版本格式（官方仅提供 “推荐方案”），导致不同项目的版本号规则五花八门，增加了认知负担：

• 格式碎片化：常见格式包括 YYYY.MM（如 Ubuntu 20.04）、YY.MINOR（如 PyPI 某些包）、YYYY.MM.PATCH（如 Terraform 0.12.0 后转向混合方案）、YYYY.MM.DD（如每日构建版本）—— 跨项目协作时，需要额外学习每个项目的版本规则。
• 高频发布导致版本膨胀：对于每日迭代的 SaaS 产品或内部系统，若使用 YYYY.MM.DD 格式，版本号会快速变成 2024.10.28、2024.10.29，冗长且难以记忆；若简化为 YYYY.MINOR，则无法区分同一月份内的多次 bug 修复。
• 低频率发布导致版本 “断层”：对于半年 / 一年发布一次的项目（如某些工具类开源库），版本号会出现大跨度跳跃（如 2023.1 → 2024.1），用户无法从版本号判断中间是否有重要更新，甚至误以为项目已停止维护。

迭代节奏受时间绑架，易引发质量问题​

CalVer 将版本发布与时间强绑定，可能导致团队为了 “凑时间节点” 而牺牲软件质量：

• 仓促发布压力：若团队承诺 “每月发布一个版本”（如 2024.10、2024.11），即使功能未完成或测试不充分，也可能为了维持版本号的时间连续性而强行发布，导致线上 bug 增多。
• 无意义版本泛滥：某些月份可能仅修复了 1-2 个微小 bug，却需要发布一个全新的 “月度版本”（如 2024.12），既浪费发布资源，也会让用户对 “版本更新” 产生麻木感（频繁更新但无实质价值）。
• 无法灵活调整迭代周期：若业务需求变化导致需要延长 / 缩短发布周期（如从月度改为双周），版本号会出现逻辑混乱（如 2024.10 后直接跳到 2024.10.1），破坏用户对版本节奏的预期。

不适合长周期维护与向后兼容场景​

现有软件生态（包管理器、CI/CD 工具、监控系统）大多是为 SemVer 设计的，CalVer 可能面临兼容性问题：

• 包管理器解析异常：npm、pip、Maven 等工具默认支持 SemVer 的 “版本范围匹配”（如 ^1.2.0 表示兼容 1.x.x 所有版本），但 CalVer 无统一的 “兼容性规则”—— 若项目用 2024.10 表示月度版本，用户无法通过版本范围快速锁定 “兼容的旧版本”，只能手动指定具体版本号。
• CI/CD 自动化适配复杂：部分自动化工具（如自动更新依赖的脚本、版本对比工具）依赖 SemVer 的语义规则判断 “是否需要升级”，而 CalVer 只能通过时间戳判断新旧，可能导致 “不必要的升级”（如从 2024.10 自动升级到 2024.11，但后者包含破坏性变更）。
• 跨版本协作沟通成本高：若团队中部分项目用 CalVer，部分用 SemVer，跨项目依赖时需要额外对齐版本规则 —— 例如：A 项目（CalVer 2024.10）依赖 B 项目（SemVer 2.3.0），开发者需要同时理解两套版本逻辑，容易出错。

用户认知与信任度问题​

CalVer 的版本号对普通用户（尤其是非技术用户）不够友好，甚至可能影响产品信任度：

• 版本 “新旧” 判断反直觉：对于低频更新的产品，用户可能误以为 “版本号越新（时间越近）功能越全”，但实际可能只是修复了 bug；反之，某些旧版本（如 2023.06）可能比新版本（2024.01）更稳定，但用户会倾向于选择 “时间更新” 的版本，导致不必要的升级风险。
• 项目活跃度误判：开源项目若长时间未发布新版本（如 2022.01 后无更新），用户会通过版本号直接判断 “项目已死”，但实际可能是团队在专注维护旧版本或开发重大功能 —— 而 SemVer 中，1.2.3 之后即使隔两年发布 1.3.0，用户也能理解是 “功能迭代” 而非 “项目复活”。
• 企业客户决策困难：企业客户采购软件时，通常会关注 “版本稳定性” 和 “支持周期”，但 CalVer 无法从版本号中体现这些信息 —— 例如：2024.10 可能是刚发布的不稳定版本，而 2023.06 是经过长期验证的稳定版，但客户可能更倾向于选择 “时间更新” 的版本，导致决策失误。

场景​

总结​

CalVer 的核心矛盾是 “时间优先” 与 “软件语义需求” 的冲突 —— 它将版本号的核心功能从 “描述软件状态” 扭曲为 “标记发布时间”，导致版本号失去了对 “功能、兼容性、稳定性” 的标识作用。

这些缺点并非 “不可缓解”（例如通过 “CalVer + 语义后缀” 混合方案：2024.10.1 表示 2024 年 10 月第 1 个补丁版，2024.11-beta 表示测试版），但无法从根本上解决 —— 混合方案本质上是向 SemVer 妥协，反而增加了版本规则的复杂性。

因此，CalVer 更适合 “不依赖他人、用户直接使用、快速迭代、无需严格兼容性承诺” 的场景（如 SaaS 平台、内部系统、消费级 App），而在 “供他人依赖、需要长期支持、严格兼容性保障” 的场景中，SemVer 依然是更稳妥的选择。

使用Lighthouse进行性能优化​

在某个页面打开调试工具，切换到Lighthouse，然后选择模式，设备类型，最后点击右上角的分析页面负载。等的生成测试报告，针对性的优化即可。

优化常用方法​

• 启用HTTP2,甚至HTTP3
• 开启网络传输压缩：gzip等
• UI图片尽量使用webp，且压缩到合适的大小
• css,js等文件需要压缩后，再投入生产环境使用
• css,js等静态文件，如果可以，尽量主动设置请求头缓存。（但需要考虑副作用，设置后，必须改变文件名才能获取到最新的文件，对构建性应用友好，因为每次都会生成新的文件名，浏览器环境谨慎使用。）
• 不影响页面渲染的css可以延迟加载<link href="xxx.css" rel="preload" as="style" onload="this.rel='stylesheet'">
• 屏幕外的图片使用延迟加载，需要设置固定占位宽高。<img loading="lazy" class="size-[40px]" ... />

一对一关联​

表结构​

用户表，头像表

users
id
nickname

avatars
id
user_id

定义模型​

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    public function avatar()
    {
        return $this->hasOne(Avatar::class);
    }
}

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Avatar extends Model
{
    public function user()
    {
        return $this->belongsTo(User::class);
    }
}

php8.0​

命名参数​

• 仅仅指定必填参数，跳过可选参数。
• 参数的顺序无关、自己就是文档（self-documented）

php7

htmlspecialchars($string, ENT_COMPAT | ENT_HTML401, 'UTF-8', false);