自己一个人在搞一个小网站, 一直在踩坑, 每次碰见问题都要花大量时间来测试和解决, 学习新知识感觉影响了身心健康, 解决不了就吃不香睡不好, 还要熬夜, 导致第二天白天什么也不想干.
碰见的好多问题都是新问题, 网络教程都是旧的, 并且无法信任 AI.
举几个这几天部署网站和搭建日志平台碰见的例子, 还有好多没写上. 太长可以选择性地看.
1.申请免费泛域名证书, 网上教程没几个新的, 搜出来都不好用, 挨个摸索最后 acme.sh 成功了, 花了一大堆时间.
2.Nginx 开 Http2, 按网上教程写了配置之后提示语法过期, 搜索解决办法又花了一大堆时间.
3.Nginx 部署了多个域名, 但是我想我万一要改其中一个, 必须停掉, 其他网站就不能用了, 于是我单独起了一个 Nginx 当反向代理, 每个域名再自己起一个 Nginx.
4.Docker 环境启动 Nginx 反向代理, 应用内部互联必须用服务名或容器名, 结果我写 docker-compose.yaml 的 depends_on 启动顺序必须使用服务名, 不能想当然用容器名.
5.然后去搭建日志平台了, 搜了一大堆教程, 中文网教程都是旧的或者不能用的, 最后花了大量时间搜出一个 Grafana Loki Promtail 组合, 直接拿官方教程给的 docker-compose.yaml 在自己的 Windows 启动起来了.
www.hesudu.com/t/1076615＃reply6
6.然后去开发我的 Nest 后端日志了, 搜索结果一大堆选了 Pino, 然后发现 Pino 这东西在控制台输出中文是乱码, 官方一大堆理由然后给了个临时生效的命令, 我 TM...
7.怎么把 Window 本地 Docker 环境 部署到云服务 Linux 上花了一大堆时间.
www.hesudu.com/t/1086033＃reply66
8.部署到服务器上了, 发现我这个 Grafana Loki Promtail 日志三件套岂不是每个网站应用都要装一遍, 然后我就搜了一大堆发现 Docker 有个驱动插件自动给 Loki, 服务日志直接打印到 stdout 就行, 然后我之前 Nest 后端日志全作废了, 时间白花了, 我 TM...
9.然后我就测试 Grafana Loki Promtail 三件套, 发现它竟然在公网不用密码就能访问, 结果官方给的 docker-compose.yaml 默认开启了匿名访问, 我 TM...

搭建了日志平台就无聊看日志呗, 发现 Nginx 反向代理的上游服务器接收到的 IP 地址竟然是 Docker 的 IP, 解决这个又花了一大堆时间.

继续无聊看日志, 结果发现所有 Docker 容器内部全都比宿主机差 8 小时, 又花了一大堆时间搜解决办法.

继续无聊看日志, 结果发现有攻击者或者扫描器访问我/api 路径, 但是我后端的 prefix 真的是 /api, 直接访问 Node 服务器了, 又花了一大堆时间解决.

我服了啊, 我好累啊, 感觉未来毫无把握.

史上最垃圾的文档排版 Grafana Loki 当之无愧
grafana.com/docs/loki/latest/configure/
根标签在最右侧, 只有一个几百像素高的可滚动的 TOC 导航
中间内容是配置, 加粗字体是根标签,
可滚动的区域是根标签下面的子标签, 内容超级多, 并且中间区域无法触发页面翻译

忍无可忍, 此油猴脚本可以优化 Loki 配置页面布局

// ==UserScript==
// @name Customize Grafana Loki Docs Page
// @namespace tampermonkey.net/
// @version 0.3
// @description Modify the max-height of .toc-scrollable to 100vh, remove specific divs, and change padding of docs__toc--wrapper on Grafana Loki Docs Page
// @author You
// @match grafana.com/docs/loki/latest/configure/
// @grant none
// ==/UserScript==

(function() {
'use strict';

// Create a style element to override styles
var style = document.createElement('style');
style.type = 'text/css';
style.innerHTML = `
.toc-scrollable {
max-height: 100vh !important;
}
.docs__toc--wrapper {
padding-top: 0px !important;
padding-left: 1rem !important;
}
`;
document.head.appendChild(style);

// Function to remove specific divs
function removeElements() {
// Select and remove the feedback title div
var feedbackDiv = document.querySelector('.docs__feedback--title.flex-direction-column.align-items-start.pb-1');
if (feedbackDiv) {
feedbackDiv.remove();
}

// Select and remove the toc-heading div
var tocHeadingDiv = document.querySelector('.toc-heading');
if (tocHeadingDiv) {
tocHeadingDiv.remove();
}
}

// Run the remove function
removeElements();
})();

在把这条 CSS 样式加到上面, 效果更好
pre {
font-size: 14px;
line-height: 1.2;
}

想太多了，他妈的烂命一条，就是干，就是梭。
服务宕了就重启，数据丢了就恢复。
上来就搞容器部署？开什么玩笑，pm2 start 就是干。

你费老大劲大概率也没人用，还不如自己开心梭哈，想怎么来就怎么来。

加一个兴趣群，问老哥

怕毛，以前搞过个 APP ，有大几千用户了， 心血来潮想改下数据表结构

思考了十分钟直接把所有用户删了

重新建表

这怎么就踩坑/无力了？学新东西不都是这样吗。。

我认为这是一个进步的过程，如果毫无痛苦而言，说明替代性也很高，你学到的是实打实的经验。不过也可以适当向大家问问如何获取有效答案通过互联网，比如我现在问 GPT ，也经常会问到一些无效且过时的问题，然后如果再在 StackOverflow 上查不到，我就会直接放弃....

你为啥不写个迁移脚本，这么猛。。。

用 Cursor ，困难说明进步大

简中互联网就是垃圾堆，英语不好的开发人员，不得不每天翻垃圾找吃的。

这是你进步的过程

你为何官方文档不去看？却要去百度搜一大把那种你都认为过期的教程呢？是看官方文档更痛苦吗？如果是这样，劝你还是放弃这一行。

那个时候比较愣头青，搞个功能也不想以后的兼容性，就想马上搞出来，然后过两天又有新想法了，之前的设计又不够用了，头脑一热就删数据库重新搞。。

先把搜索引擎换成 google

op 哥，你这个基本功不够扎实啊。
后面的我也懒得看了。
第一条 certbot certonly --manual --preferred-challenges dns -d *.zzz.com -d zzz.com 不完事了嘛。。。

遇到问题，第一时间应该是去看官方文档，而不是去搜索引擎。。。

高情商回复： 没关系的，每个人都是这么过来，这样你的技术就棒棒的

真实回复： 其实还是太菜了还不愿意花钱； 这种事情找人学习下提问方法配合 ai ，没有搞不定的。

最终答案只有一个 那就是 Eating your own dog food
zh.m.wikipedia.org/wiki/%E5%90%83%E8%87%AA%E5%B7%B1%E7%9A%84%E7%8B%97%E7%B2%AE
踩坑意味着含有不可控性

啊？踩坑踩完不是应该学到很多东西，所以感觉很有成就感吗？自己搞完之后可以挑有意义的写点博客记录一下，一方面以备以后可能有用，一方面也可以给其他新人贡献经验

不然就得三天两头找新东西然后又不甚满意然后再继续找的循环 这种行为我认为很傻的

通常学到的东西没有意义的 含金量明显不足
通常也只有该软件适用

之前确实向你一样, 我也有自己的博客, 但是现在我看了看几年前写的各种踩坑博客发现, 这些坑随着版本更新完全就不可用了, 合着纯白费时间, 我是一个前端程序员出身... 众所周知前端界是出了名的造轮子, 各种框架经常更新, 没几天说不定这个配置就 deprecated 了, 哪个项目过了一段时间就启动不起来了, Vue 作者都说了, 文档上列一堆坑真的好吗? 这些就比如 Nignx Loki 文档通篇列了一堆配置和参数就完全不管了, 不看教程根本就没法快速了解这些配置. 当然我觉得他们肯定也可能是故意的, 买他们服务就告诉你到底怎么用了. Nest 官方就有课程, 我还真看了, 比只看文档差远了.

记一套搭建流程就行，怎么做就行，其他坑根本不需要做笔记。就是做了笔记后续二次查看的概率很低。

最优还是把能写成自动化脚本的全部放脚本里，坑踩一次就行了，不能用了或者发现更优方法再更新脚本就行了，真手动写这些玩意配置什么的不得累死，脑容量都不够用。

读书百遍其义自见，一样的道理吧。

以前没有容器化的时候，学 LNMP ，就是买个阿里云的 ECS ，一步步的搭，错了就重置 ECS 重新装...

我以为要装 100 遍才会呢，50 多遍我就能闭着眼睛装了...

技术坑基本上不会白踩，但 AI 应该多多利用
AI 的最大好处就是可以帮你快速入门一项技术、快速了解完成一件事情大概有哪些步骤和用到的工具，这样可以少走弯路，减少挫败感

人会有分两种不同偏好的学习方式： 理论先行 和 实践先行。以此衍生出来 4 个象限
基于不同的偏好文档的好坏评价也是不一样的。

---

不管是技术笔记，还是官方文档，都不适合照搬照抄。很多文章发布超过 300 天的，剩余的价值只是他的思想了。

我一般都是直接看最新的文档，而不是看别人的分享。
只有来来回回看不明白、理解不了的部分，才会单独检索查看别人的分享，去针对性的加深学习。

但是很多库和工具，也许只是实现了作者的某一个想法或者辅助他实现某一个功能。
并不一定会觉得说会有很多人去使用，所以并不一定会有很完善的文档。不可避免的会有很多困扰。

至于中文内容的落后是没办法的。英语作为世界语言，绝大多数的文档和资料都会优先考虑英语作为主要语言。其他语言作为原文档的翻译肯定会落后一段时间。
各种库对于中文的支持也是，很多开发者并不会考虑不同语言的输出。才会有各种分享说不要用中文目录之类的。
同样的很多的库也都没有很好的支持 RTL

我觉得你还是信任一下 ai 比较好，官网文档> AI>=英文教程>中文教程，此外，搜索引擎可以选收录时间，选个最近一年的。
不信你把这 10 个问题重新扔给 chatgpt...我看了一下，至少有 8 个回答是靠谱的..
depends_on 那个，减少一些想当然就好了...，
还有那个 grafana 的文档，toc 的高度，你把下面那个 grafana cloudcloud 关掉,toc 就是页面高度了吧，我这边沉浸式翻译也可以正常触发翻译效果..

server {
listen 80;
server_name xxx.com;
proxy_connect_timeout 10;
location / {
proxy_pass 192.168.116:8080;
}
}

server {
listen 80;
server_name xxx.cn;
proxy_connect_timeout 10;
location / {
proxy_pass 192.168.50:8080;
}
}

写的很好, 很受启发, 我在不同的状态会在这几种里切换, 时间少任务紧时 stackoverflow 搜问题, 很多时候问题都不看完, 直接看回答. 有官方文档就看 reference 也可以快速解决问题. 学习时快速上手看教程, 深入理解看原理解释.

现在有了 ai 了 ai 搜索能解决很多常见问题，很好的
有个专业领域的开源 sdk 不懂怎么用，一步步地去翻源码调试，已经搞了四五天了，昨天一整天心情崩溃就在电脑前大吼大叫，希望邻居没有觉得我扰民- -
我个人的体会就是还是要努力，要让自己的双手沾满泥土，不能颓，不然为什么成功的是你不是别人呢

多看官方文档，少看野鸡博文。

从 0-100 是这样的 很多是需要耐心 沉下来去了解的 也不是会一下子都了解完的 可以把目标定小点 并且把笔记完善下 总结下相同和不同点 还有部署的部分

第一条 你这证书只有 90 天啊 记得搞一个自动化续签的

写的很好，发现新大陆的感觉。我才知道我自己是实践先行的类型。

同前端，Nginx/Docker/Grafana 这一套部署，不算是“困难”的范畴，但也是要花费不少时间精力的。啥都会 === 啥都不会。

我只会在想要深入的方向上“为难”自己。其他东西尽量挑选一个“用户友好”的替代品。
比如 Nginx -> Caddy, Docker 用 Portainer 管理，Next 部署在 vercel/netlify 上。

no code, no bug.

不得不承认学习新知识都是要摸索 踩坑的。我本地搭建 drone+gogs 进行 cicd ，尝试了几乎一整个国庆。。。而且在此之前也尝试过几次，直接放弃的那种。。。

这不是挺好的吗，等你见多不怪时，就会感觉打通任督二脉，技术不再是让你头疼的问题。转而头痛的是怎么将技术转化为收入。

看起来是你学习了不少东西，还不开心

多看官方文档吧，你这好多问题都很好解决。
尤其是第 3 条，没看懂为啥要这么多 nginx 。nginx 配置文件可以拆分，一个域名对应一个文件。
重载配置命令 nginx -s reload ，耗时不到 1s ，压根也不需要停掉啊。

我自己学习也是这样子的，就是不断踩坑，然后解决问题
就是一个学习的过程吧
搞不好也会心烦，总想着要搞好才罢休，不过整好了之后，成就感是满满的
感觉 op 可以先给自己定一个目标，做到了就歇一会。使用的过程中遇到了不爽的点，就再定一个目标再去解决
学习是需要持续的激励的，折腾不是目的，折腾之后用的爽才是
可以多了解一下业界解决这个问题的最佳实践
还是建议写个博客记录一下，主要是给自己看的，因为搞了一遍之后很快就会需要搞第二遍的 /doge

基础知识不够吧。。。所以有下深水的窒息感，有些套路要借鉴一些现成经验会快很多