Claude Code通关手册(一):转角遇到爱,真香体验
💡Tip这是Claude Code通关手册的第一篇。本系列将带你从零开始,系统掌握Claude Code的完整知识体系,从CLI命令到自动化工作流,从个人使用到团队协作。 AI发展如火如荼,你可能已经在使用各种AI编程工具。每天打开编辑器,自动补全代码、生成测试用例,或协助编写需求代码。在编辑器中与AI交互,通过不断修改完善,工作效率得到显著提升。 然而,大名鼎鼎的Claude Code安装完成后,仅呈现为一个简单的命令终端。这个看似简陋的终端工具中,却蕴藏着一套与其他工具截然不同的AI编程哲学。 今天这篇文章,我不会铺天盖地讲解其功能列表,而是带你搞清楚三件事:Claude Code的具体价值、快速安装并运行Claude Code,以及它为何能火遍全网,让人爱不释手? Claude Code的价值Claude Code与其他AI工具不同,它开启了一个新的竞争赛道。打个比方你就会明白: 去厨房做一顿饭: Copilot 是菜谱App。搜索”番茄炒蛋”,它告诉你:番茄切块、鸡蛋打散、热油下锅、先炒蛋再炒番茄……步骤写得清清楚楚,但切菜、开火、翻炒、调味,全是自己...
uniCloud加速GitHub Pages博客访问
GitHub Pages 提供了免费、便捷的静态网页托管服务,让我们可以轻松地将博客部署在 GitHub 上。然而,由于网络原因,国内访问 GitHub 的速度往往不尽如人意,严重影响博客的加载体验。 有没有一种既经济又能显著提升访问速度的方案呢?uniCloud 前端网页托管 就是一个不错的选择。它提供了免费的云服务空间,对于个人博客来说,资源配额完全够用,并且在国内的访问速度非常理想。 👉 uniCloud 前端网页托管官方文档 在之前的文章 从零到一键发布:Obsidian + Hexo + GitHub Pages 个人博客搭建指南 中,我们已经实现了将 Hexo 博客自动部署到 GitHub Pages。本文将在此基础上进行改造:将生成的静态网页从推送至 <用户名>.github.io 仓库,改为部署到 uniCloud 的云存储空间中,从而实现国内访问加速。 操作步骤创建 uniCloud 服务空间 访问 uniCloud Web 控制台,注册并登录账号。 点击 新建服务空间,创建一个新的云环境。 在云服务商选择中,建议选择 支付宝云 / 阿里...
Hexo 插件:自动转换 Markdown 相对路径链接
在本地用 Markdown 写文章时,我们常用相对路径引用其他文章,例如: 1[Hexo永久链接最佳实践:终极方案与优化指南](./Hexo永久链接最佳实践:终极方案与优化指南.md) 但 Hexo 在生成静态页面时,会将上述语法直接转换为: 1<a href="./Hexo永久链接最佳实践:终极方案与优化指南.md" target="_blank"></a> 由于浏览器无法解析 .md 文件路径,导致超链接失效。 解决方案在 Hexo 项目根目录下创建 scripts/fix-relative-links.js 文件,并添加以下代码: 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991...
Hexo 搜索跳转失效?一招解决链接域名丢失问题
问题现象:博客搜索功能正常,但点击搜索结果后跳转链接丢失了站点域名,例如实际文章链接为 http://www.gloam.cn:4000/20260302020433.html,搜索后却指向 http://20260302020433.html,导致无法访问。 根本原因:Hexo 搜索插件在生成搜索数据时,只记录了文章的相对路径(即 permalink 配置值),没有自动补全站点的完整域名。 解决方案:修改主题中负责渲染搜索结果的 JavaScript 文件,将文章的相对路径拼接上站点的根路径(如 location.origin),生成绝对链接即可解决。 问题复现根据 Hexo永久链接最佳实践:终极方案与优化指南 对文章的url进行了优化,但是优化后通过搜索无法跳转到正确的文章。 12345实际链接:http://www.gloam.cn:4000/20260302020433.html搜索后跳转链接:http://20260302020433.html 修复指南定位搜索功能相关文件在主题目录中寻找负责搜索的脚本文件。以 hexo-theme-matery 主题为例,需要找到...
Hexo永久链接最佳实践:终极方案与优化指南
结论先行:日期方案是最佳选择经过多种方案的对比与实践,推荐使用基于文章创建时间的日期格式作为永久链接,即: 1permalink: :year:month:day:hour:minute:second.html 该方案完全依赖 Hexo 原生功能,无需额外插件;生成的 URL 简洁、无中文乱码、长度固定;只要在每篇文章的 Front-matter 中明确设置 date 字段,链接即可永久不变,彻底解决了文件名修改、中文转义等痛点,是兼顾 SEO 与稳定性的最优解。 下面详细分析各方案的优缺点,根据实际需求选择。 默认配置Hexo 生成永久链接的常规设置位于站点根目录的 _config.yml 文件中,如下所示: 12345permalink: :year:month:day:hour:minute:second.html permalink_defaults: pretty_urls: trailing_index: true # 设为 false 可移除 URL 末尾的 'index.html' trailing_html: true #...
图片压缩与格式优化指南
太大的图片不仅会影响加载速度,而且会让捉襟见肘的网站流量变得更多,为此有必要在上传图片前先确认下图片的大小,如果图片太大建议先进行一下图片的压缩。 图片压缩那么如何压缩图片呢?个人使用的是一个在线的网站工具:tinypng.com,完全免费,可以批量压缩 20 张图片,最大 5MB。 该网站还提供了: API ,开发者可以调用它来为自己的产品提供图片压缩服务,但每月只能调用 500 次。 Mac 的桌面端工具 TinyPNG4Mac,开源在 GitHub,可以压缩超过 5M 的图片。 webp / avif 格式webp 和 avif 格式比起传统的 jpg 格式体积更小,也是目前非常主流的图片格式。 WebP 使用了更优的图像数据压缩算法,能带来更小的图片体积。例如微信文章里的很多图片都是 webp 格式。avif 格式压缩的更厉害,体积更小。一些主流网站使用的图片就是avif格式的。 但是这两种格式得考虑兼容性问题,读者可以去 caniuse.com 搜索各大浏览器的兼容情况。 感兴趣的同学可以参考以下博客进行了解 什么是WebP?使用WebP格式的图片提供网...
Hexo插件:移除图片默认 alt 属性
Hexo 生成图片时,若未手动设置 alt,默认使用文件名作为替代文本,可能导致无意义内容。若希望彻底移除所有 <img> 标签的 alt 属性,在主题或者根目录的scripts/remove-img-alt.js里加入以下代码, 1hexo.extend.filter.register('after_render:html', function (str) { return str.replace(/<img(.*?)alt=".*?"(.*?)>/g, '<img$1$2>'); }); 此代码在 HTML 渲染后移除所有 alt。 注意:这会一并删除手动添加的有意义 alt,请按需使用。 scripts这个文件夹需要自己创建,Hexo 的规则是: 只要在 Hexo 根目录或主题目录(和 _config.yml 同一层级)下有 scripts/ 目录,里面放的 .js 文件会在生成站点时自动执行。
Hexo移除图片默认 alt 属性
Hexo 生成图片时,若未手动设置 alt,默认使用文件名作为替代文本,可能导致无意义内容。若希望彻底移除所有 <img> 标签的 alt 属性,在主题或者根目录的scripts/remove-img-alt.js里加入以下代码, 1hexo.extend.filter.register('after_render:html', function (str) { return str.replace(/<img(.*?)alt=".*?"(.*?)>/g, '<img$1$2>'); }); 此代码在 HTML 渲染后移除所有 alt。 注意:这会一并删除手动添加的有意义 alt,请按需使用。 scripts这个文件夹需要自己创建,Hexo 的规则是: 只要在 Hexo 根目录或主题目录(和 _config.yml 同一层级)下有 scripts/ 目录,里面放的 .js 文件会在生成站点时自动执行。
jsDelivr 缓存刷新与版本控制
目前 jsDelivr 是一个免费,开源的加速 CDN 公共服务,可以使用 jsDelivr 来做 CDN 加速。 如果更新了版本,通过jsDelivr的链接是无法马上看到的。jsDelivr 的缓存更新时间是 24 小时。 强制刷新如果你需要刷新cdn内容,可通过以下两种方式手动清除缓存: 直接访问刷新链接 在原链接域名前加上 purge. 前缀。 例如原链接: https://cdn.jsdelivr.net/gh/user/repo/file.css 刷新链接: https://purge.jsdelivr.net/gh/user/repo/file.css 使用官方刷新工具 访问 Purge jsDelivr CDN cache,在页面中输入需要刷新的 URL 并提交。 强制刷新后,由于全球边缘节点同步需要时间,部分节点可能仍未更新,因此刷新后立即访问原链接仍有可能看到旧内容。等待y一段时间后再试通常可解决。 推荐方案:使用版本号控制为彻底避免缓存问题,最可靠的方法是在链接中加入版本号(或 commit hash、标签)。 1https://cdn.j...
从零到一键发布:Obsidian + Hexo + GitHub Pages 个人博客搭建指南
前言我一直使用 Obsidian 管理笔记,它很好地满足了我的写作需求。但我始终渴望拥有一个属于自己的博客——一方面希望将积累的知识分享出去,获得反馈;另一方面,通过维护博客倒逼自己持续写作和总结,提升表达能力。 本文将完整记录我搭建博客的过程,并重点解决从 Obsidian 写作到博客发布的自动化流程。如果你也想打造一个“赛博小窝”,希望我的经验能给你带来一些参考。 搭建方案我的博客基于以下工具组合实现: 写作端: Obsidian,笔记的写作组织工具。 同步插件:Enveloppe:将本地文章同步到GitHub的Obsidian插件。 博客框架: Hexo:博客站点使用的框架。 主题:hexo-theme-matery:简洁美观的响应式主题。 托管平台:GitHub Pages:免费静态网页托管。 由于我不希望公开所有文章的源文件,我创建了两个 GitHub 仓库: 私有仓库 hexo-project – 存放 Hexo 博客配置、主题和文章源文件。 公共仓库 <用户名>.github.io – 存放 Hexo 生成的静态文件,供 GitHub Pages...
解耦复杂业务:基于责任链与上下文的重构实战
起因在版本迭代的过程中发现,订单计算的方法过于复杂,在新增或者修改功能时往往需要通篇将方法通读一遍甚至多遍,不能迅速找到应该修改的地方进行功能的改造,通过分析发现存在以下的缺陷(姑且称之为缺陷) 没有进行逻辑划分,代码行数太长 没有进行有效的封装抽象,虽然将部分代码封装成函数,但是函数放在一个类中,又造成了订单服务这个类变成了大泥球的类 业务逻辑不统一,比如签名校验的逻辑散落在方法的各个地方 业务语义性不强,各种get set遍布,无法体现出业务的含义 重构过程 过程分解对于复杂度较高的代码,无论是进行代码的重构还是在此基础上进行功能的迭代,对于过程的分解是必不可少的。通过通篇阅读代码,整个订单计算的逻辑可以分解为几部分组成 得到上面分解后的逻辑,那么想到的自然是分而治之,根据分解的逻辑将功能抽象到一个方法中,然后在订单计算的方法中进行依次调用即可。这样做虽然能够将订单计算的逻辑整理的相对容易阅读,但是所有的业务代码全都写在订单业务的一个类中,造成类的膨胀,让订单业务类变成一个大泥球的类,影响这个类的可阅读性,而且也不能做到逻辑代码的整体复用。 那么我们就需要将这些业务逻辑...
单元测试的困境与破局:为何我们不愿写,以及如何高效地写
单元测试作为软件质量的重要一环,往往在整个开发流程中被大多数开发人员所忽略,本文旨在分析如何写好单元测试并探索一些测试驱动开发的应用。 单元测试原则在写单元测试前,先要明确什么是单元测试,单元测试的原则是什么?明确这些问题前不妨先参考一下前人总结的单元测试First原则。 在工作过程中经常见到一些无效的单测,通常是启动Spring容器、连接数据库、调用方法,最后控制台输出结果,这种并不能称之为有效的单测。 12345678910111213@RunWith(SpringRunner.class)@SpringBootTestpublic class HelloServiceTest { @Autowired private UserService userService; @Test public void addUserTest() { AddUserRequest addUserRequest = new AddUserRequest("zhangsan", "1886589985...








