Colin_Downey P.S. 这个贴成功成为近半年最热闹的帖子，哈哈哈

是这样了哈哈，或许可以叫 ”一起来折腾博客“。

另外，热闹的应该不叫帖子，叫”话题“、”讨论主题“合适一些（在论坛软件 Flarum 里面这个叫 ”discussion“，URL 上也是 "discussion" 的缩写 "d"）

    Colin_Downey
    是的，hexo g -d才是正统且快速的做法。由于这篇文章是面向无基础的同学，不想涉及npm插件和.yml修改，所以才采用了copy的方法。

      MikyMing
      自从我发现zeit now 对个人用户免费不限流量之后特意开了一个私仓把图片部署到now上了🤭
      写的话一般直接VSCode或者直接在GitHub上写了，因为GitHub上.md后缀有Preview。commit一下后面就全自动了。

      如果图片放本地asset_folder的话可以试试 https://github.com/fengkx/hexo-native-lazy-load 本地图片可以直接读取宽高完全不reflow的lazy load。

          0x709394
          get lazyload！很有用的插件。另外zeit now大赞！正好看到

            0x709394 那个%20真是玄学！！！没道理官方文档都会有问题啊。。。 图片好像没问题？谁再看看。。。

                Bintou
                开源的看看代码就知道了。
                下面看的是它的旧版。我从footer那里的链接点进去是旧版所以猜测老师用的是旧版的Next。
                https://github.com/iissnan/hexo-theme-next/blob/master/layout/_partials/header.swig#L43
                这里就是生成url的地方。

                 {% for name, path in theme.menu %}

                这里的theme.menu就是主题的config。https://github.com/iissnan/hexo-theme-next/blob/master/_config.yml#L94
                name是键， path 就是值，然后经过模板的这么一个函数和pipe就成了渲染出来的url。
                url_for(path.split('||')[0]) | trim
                config文件中也有注释的。我不太了解swig的trim。还有为什么他要先url_for 然后再trim而不是先trim。所以我才会说

                0x709394 估计是yaml哪里多了个空格。

                但是如果trim了的话是不应该有%20。老师可以试试在模板里面log看看是什么原因吧。

                图片的话首页确实可以显示，但是点到文章里面就不行了 https://lbwang.github.io/2020/04/07/sidh/ 路径在那堆日期后面的相对路径了。

                      0x709394
                      折腾了一个上午，似乎都不成功：
                      1、插入图片那里，我按帖子装了asset-folders，但是现实不成功。hexo g有这个输出：update link as:-->/.io//ec.jpg ，ec.jpg只是我测试用的图片。这个link显然不对啊！

                      2、还有，支持LaTex那里，按hexo-renderer-markdown-it-plus 去做，也不行。不知道为何。想用hexo-renderer-markdown-it-plus的原因，就是hexo-math的LaTex语法好奇怪。不知道在theme那里需要设置什么。我用的是next。next支持mathjax和katex的。

                      有空帮忙看看。

                          Bintou hexo g有这个输出：update link as:-->/.io//ec.jpg ，ec.jpg

                          这个应该不是 hexo-asset-image 的输出来的。除了安装，图片也应该放在assert folder也就是跟md文件同名的文件夹里面。在 site config 里打开之后每次hexo new都会自动创建。用不到的话可以删掉。然后markdown的路径也按照README写的那样应该就好了。

                          Bintou 看了这个帖子 . 似乎可行。需要修改一个index.js 文件。

                          我记得之前是要改，但是某个版本更新了之后不改也行了现在。毕竟直接手改node_modules不是什么好习惯。

                          LaTex 具体什么问题我也不清楚。hexo-math 和 markdown-it-katex 是不能同时装的。排查的话首先看一下public有没有引入到 katex 的 CSS。 如果有的话，看看是不是因为 markdown 中 LaTex 的一些转义的坑或者是markdown-it-plus 的config 的问题吧。可以copy一份现成的然后再去调整（控制变量😂）。如无意外应该是这样的。

                              7 天 后

                              刚好前不久重整了下自己的GitHub page博客，分享一下。
                              这次我用了GitHub action，主分支放所有的md文件，再开一个分支放hexo的所有配置，让action去自动build+deploy博客，我只需要写好md推上去就行了。
                              这样的好处有几个（发这个评论时只凑出三个23333）：

                              1. 不想氪金又没得白嫖GitHub会员的情况下，可以让自己的博客源文件闭源
                              2. 基本不用担心迁移的问题，因为只需要维护md文件，甚至可以直接在GitHub网页上写博客
                              3. 博客项目看起来更清晰

                              另外，我还在action里监控着我这个私有仓库的star事件，点一下star就可以发布博客。目前还有很多有趣的骚操作在酝酿中，没具体做出来就不说了，不知道可行性有多大。
                              或许可以搞一个通用的action来简化所有操作？进一步的，或许可以搞个东西来自动生成定制化的action.yml，方便各种群体？第二个是写评论时想到的，因为突然想起我物理系的朋友听完我这个博客方案懵掉了哈哈哈，这个东西可以直接前端js生成就好了，就酱~

                                重开一条评论，对于hexo，我一直有个问题没能解决。我写文章都是：post下所有的md文件所用到的图片都放在post/images里面，而网上的hexo图片方案都是要xxx.md的图片放到xxx文件夹，这对我很不方便呀。同时，我一般是相对路径引用图片。对于这两个问题，有什么解决办法吗？
                                我现在是自己写个小插件处理图片路径到博客的根目录，然后build完后把整个images移动到根目录。

                                  Error 不想氪金又没得白嫖GitHub会员的情况下，可以让自己的博客源文件闭源

                                  大概是去年 GitHub 的私有仓库就免费了。

                                  昨天他们又进一步放开了免费方案（

                                      重开一条评论，对于hexo，我一直有个问题没能解决。我写文章都是：post下所有的md文件所用到的图片都放在post/images里面，而网上的hexo图片方案都是要xxx.md的图片放到xxx文件夹，这对我很不方便呀。同时，我一般是相对路径引用图片。对于这两个问题，有什么解决办法吗？
                                      我现在是自己写个小插件处理图片路径到博客的根目录，然后build完后把整个images移动到根目录。

                                        0x0001 对，但是不氪金的话，私有仓库是不能开GitHub page的，我这个曲线救国23333，在私有仓库上存源文件，自动部署到公开仓库

                                            Error 还有这一层的限制 🤯

                                            有个远程的构建机的确可以做很多事情哈哈！

                                                0x0001 对，而且私有化之后，issue什么的那些全部都没用了，毕竟这个仓库存的还是自己私人的东西，不会有其他maintainer，所以我们可以利用action的监控功能，重新定义仓库的其他功能，这就等待挖掘了，虽然可能算是滥用了

                                                    Error 不记得在哪里看到的，好像是有人拿 issue 做博客评论，然后有讨论这是否构成滥用，然后咨询了 GitHub 之后回复是只要符合 GitHub Terms of Service - GitHub Help 就可以做。

                                                    不清楚私有仓库和 Actions 是否有违反规则，大致翻了一遍，似乎没有相关的说法。

                                                      © 2018-2025 0xFFFF