在《文章固定链接的设置》和《优化博客中文章的固定链接》中本站已将文章链接设置为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的排版还怪好）