docs: 优化随机URL生成文章格式与可读性

调整文章段落间距，增加空行提升阅读体验
修复部分语句表达，使技术说明更清晰

src/content/posts/random-url-gen.md

@@ -45,10 +45,17 @@ lang: ""
 我们刚刚只是在抽象的说明某种架构 **好像** 可行，**好像** 又有什么问题，然后又有一种什么新思路 **好像** 可以解决这个问题
 
 但我们要走的路才刚刚开始，我们不妨思考一下，随机图，又或者说随机URL这类项目，服务器（如果有）究竟发送了什么给客户端，客户端又对服务器发回的报文执行了什么动作
-你肯定知道，如果想要客户端每次请求同一个URL，都返回不同的东西，那肯定是服务器针对每一个请求都返回了不同的响应，它可以是内部的，比如直接在响应体塞图片，又或者也可以是 **重定向** 
+
+你肯定知道，如果想要客户端每次请求同一个URL，都返回不同的东西，那肯定是服务器针对每一个请求都返回了不同的响应，它可以是内部的，比如直接在响应体塞图片，又或者也可以是 **重定向**
+
 直接在响应体塞图片很简单，在客户端是不可见的，当客户端请求API时，服务器直接将选中的图片作为响应体发出，在客户端看来，就好像是请求了一张图片，只不过每次刷新都不一样
+
 而响应 **重定向** 就更简单了，只需要让服务器发送一个 **临时重定向** 的状态码，比如 **302** 
-有人就会说了，为什么必须要 **临时重定向** ？因为你肯定是想要客户端每次刷新都返回不同的图，一旦你使用了 **永久重定向** 如 **301** ，客户端在收到 **301** 的那一刻就会在浏览器里写一个记录：**下次访问这个URL直接重定向，不再请求服务器** ，这就会导致你的随机图API真的就变成一张图片了
+
+有人就会说了，为什么必须要 **临时重定向** ？
+
+因为你肯定是想要客户端每次刷新都返回不同的图，一旦你使用了 **永久重定向** 如 **301** ，客户端在收到 **301** 的那一刻就会在浏览器里写一个记录：**下次访问这个URL直接重定向，不再请求服务器** ，这就会导致你的随机图API真的就变成一张图片了
+
 那么，这两种方法哪种更好呢？
 
 各有利弊，一句话说明：**直接返回MIME类型是连请求复用，仅需一次请求即可得到图片。而返回302重定向至少需要客户端请求两次** 
@@ -102,6 +109,7 @@ lang: ""
 
 # 总结
 我们共探索了三种流派
+
 - 传统派：中规中矩，在边缘函数找图，取图
 - 极客派：通过CF的规则实现在边缘找图，取图，但是不计费
 - 环保派：通过客户端JS直接在浏览器上实现找图，取图，改图