在《文章固定链接的设置》和《优化博客中文章的固定链接》中本站已将文章链接设置为domain/post_id.html的形式。
图文博客使用文件夹的形式，将文章.md和图片存储于同一文件夹。然后在构建博客后出现了问题，构建好的文章中，图片的链接构建成为domain/img，而实际图片在domain/post_id/img。这样导致了文章中所有图片不能显示。
带着问题，研究了几个解决方案，deepseek给的最便捷的解决方法是使用Hugo的页面资源（Page Resources）引用图片！[图片描述](｛｛< ref "img1.png" >｝｝)，经过试验后该代码不起作用，不知道是不是我的写法不对的原因。同时，这样在vs code中写文章的时候预览中也不会显示图片。然后deepseek又推荐了几种使用短代码的方式引用图片，同样无法在vs code中预览图片。此类方法pass。
后来想到，可以把文章的固定链接改成domain/id的形式，不要.html后缀了，这样构建好的文章.html和图片位于public目录下的以文章id命名的子目录内，两者处于同一目录内，图片可以正常引用。经试验可行。
后来又想到一种方法，修改主题模板。\layouts\_default\_markup目录下的render-image.html可以定义构建文章时引用的图片链接。原文件内容为
<img loading="lazy" src="{{ .Destination | safeURL }}" alt="{{ .Text }}" {{ with .Title}} title="{{ . }}" {{ end }} />代码意为在构建文章图片在文章相同目录。这样就好办了，找deepseek修改一下，取文章.md的Front Matter中slug的值，然后生成domain/id/img的图片引用就好了。
{{ $slug := .Page.Params.slug | default .Page.File.BaseFileName }}
<img loading="lazy" src="/{{ $slug }}/{{ .Destination }}" alt="{{ .Text }}" {{ with .Title}} title="{{ . }}" {{ end }} />这样就不用动文章的固定链接了。上面提到的ref代码不起作用可能也是render-image.html文件导致的。
之前问过deepseek关于博客网站的文章链接带不带.html结尾的问题，得到的回答大意为目前网站普遍不再使用.html结尾，搜索引擎也会更友好的对待id结尾的链接，所以当前即使有SEO的需求没有必要必须构造.html。这不在hugo的config中，这种链接被定义为了uglyURLs，丑陋的链接。
于是我又问了deepseek一个问题：
hugo和hexo等博客构建程序中，把附带.html的结尾的链接的设置项定义为uglyURLs，中文意思为丑陋的链接，请问为什么说.html结尾的链接是丑陋的链接？
以下为回答：
在 Hugo、Hexo 等静态站点生成器中，将带有 .html 后缀的链接称为“丑陋的 URL”（ugly URLs），主要源于以下设计理念和实际考量：
1. 美学与用户体验
- 简洁性：用户更倾向于看到
/about/而非/about.html。前者更像一个“资源路径”，后者更像一个“文件路径”。隐藏技术细节（如文件扩展名）能让 URL 看起来更干净、专业。 - 一致性：无后缀的 URL 更符合现代网站的设计趋势（如
https://example.com/posts/hello-world），而.html会暴露技术实现，显得过时。
2. SEO 优化
- 关键词权重：搜索引擎（如 Google）更重视 URL 路径中的关键词。例如，
/posts/seo-tips/比/posts/seo-tips.html更明确地传达内容主题。 - 可读性：无后缀的 URL 对用户和搜索引擎更友好，容易被复制、分享和记忆。
3. 服务器与路由逻辑
- 目录式结构：默认情况下，静态站点生成器会为每个页面创建一个目录（如
/about/index.html），通过服务器配置（如 Apache/Nginx）自动将/about/指向该目录下的index.html。这种结构与无后缀 URL 天然兼容。 - 扩展名无关性：URL 无需绑定具体文件类型。例如，未来若改用其他格式（如 JSON API），路径
/api/data比/api/data.json更具灵活性。
4. RESTful 设计原则
- 资源导向：RESTful 架构提倡用路径表示资源（如
/users/表示用户集合），而非文件类型。添加.html会混淆资源与文件的关系，降低 URL 的语义化。
5. 历史与技术演进
- 动态页面的影响：早期动态网站（如 PHP）常通过
page.php生成内容，但现代框架（如 Rails、Django）通过路由隐藏了技术细节。静态站点生成器继承了这一理念。 - 静态站点的“伪装”：静态站点通过目录结构和服务器配置模拟动态站点的路由体验，避免暴露自身是纯 HTML 文件的本质。
为何叫“丑陋”（ugly）？
术语源自开发者社区的约定俗成，“丑陋”并非技术缺陷，而是一种设计偏好：
- 默认禁用
.html后缀（即“漂亮 URL”）是主流选择。 - 启用
uglyURLs通常是出于兼容性需求（如托管平台限制），而非推荐做法。
总结
- 干净 URL（如
/about/）：现代、语义化、SEO 友好，符合用户直觉。 - 丑陋 URL（如
/about.html）：暴露技术细节，显得冗余，适用于特殊场景。
实际选择需权衡部署环境、服务器配置和个人偏好，但多数场景下，“漂亮 URL”是更优方案。
鉴于此，我再把网站链接改为domain/id？？
或许以后觉得public目录混乱再改为domain/post/id？？
（ps:不得不说deepseek写markdown的排版还怪好）
评论