社区系统可能存在一些潜在的缺陷，大家如果有空的话可以帮助我们一起解决。
如果你在使用社区时发现了如下类型的问题，请回帖进行反馈，并附上 bug 截图以及操作步骤：
欢迎对社区提出功能特性方面的建议，我们一起讨论，如果有可能我们会尽快实现。
在提功能建议前可以先看一下计划表，避免重复提议。
500 积分300 积分200 积分Bug 本意是指臭虫、缺陷、损坏、犯贫、窃听器、小虫等。现在人们把在程序中一些缺陷或问题统称为 bug（漏洞）。
链滴是一个记录生活的地方。
记录生活，连接点滴
B3log 社区相关的重要公告，比如新特性上线，运营策略调整等。
链滴用户指南系列帖，社区功能可在此逐一了解，欢迎讨论。
MarkDown 里不是有个代码块吗？在链滴中，或许做一个代码块直接执行的功能。
比如 Windows 端上的 cmd 命令：
pip install -i https://pypi.tuna.tsinghua.edu.cn/simple pip -U
pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple
pip install you-get
cd C:\Portable_Programes
git clone https://github.com/carykh/jumpcutter
cd jumpcutter
python -m pip install -r requirements.txt
这样的一些简单可执行的代码笔记就可以直接右键执行，省下 win + r cmd enter right click enter 的步骤了。
对上面这个需求，@CismonX 提出了看法，认为这是个伪需求：
一个正常的程序员不会在一个本地的笔记应用中写脚本，然后点进去执行
为什么不写个 shell 脚本呢？把常用的参数整理好，不比在笔记中修改要方便？
我的回答是：
对许多方便实用的命令，做成脚本不方便改一些重要参数，比如
ffmpeg -y -hide_banner -ss 00:05 -to 00:10 -i "input.mp4" -filter_complex "[0:v] scale=480:-1, fps=15, split [a][b];[a] palettegen [p];[b][p] paletteuse" "output.gif"
这条命令是将视频剪切 5s - 10s 的片段，转成 480P 15fps 的 gif。
而对另外一个视频，可能就需要剪切 15s-18s 的片段，或者改成 360P 以减少大小，就需要修改参数。
对于其它复杂的命令，还可能有更多关键参数需要调。就需要打开脚本位置，右键，点击用 Notepad++ 编辑，修改参数，保存，切换到 explorer ，双击运行。步骤有点多。
而且，一个脚本只能有一个功能，不像是 Markdown 笔记中，可以用多个代码块记录多个不同功能的命令，无论是修改，还是浏览，还是做总结，都更方便。
另外，Vditor 似乎缺少 batch 语言的代码高亮。
在代码高亮这一方面，可以把 Notepad++ 的抄过来，它在这方面支持地比较全面：
Solo 中的标签管理
碰见 2 个问题，
a. 每次发布文章时，新加一些标签，可能有时候之前已经有了，或者新加的标签与之前其实是同一个东西，但是因为描述的不同最终变成 2 个标签，
b. 当标签设置到 20+ 以上时，每次如果手动去选择记忆中已经设置过的标签的话，在所有标签中还挺难翻的，速度比较慢。（为什么不直接手动输入关键词后，自动匹配？因为有时候当操作完文章内容编辑后，此时多数操作是进行鼠标操作，和此时再进行键盘输入比较起来，通过鼠标点击选择更高效些）。
看了之前的 2 个帖子：
https://hacpai.com/article/1541384864386
https://hacpai.com/article/1494728619571
现在清理标签功能也去掉了吗？
建议：
上面的这个无序列表的缩进时手动敲出来的，不知道是因为我没有找到正确的使用方式，还是因为中间加了空白行后嵌套列表的缩进就有点乱了，还是必须手动实现缩进。
空白行可能是此处 MD 最大的杀手了吧 
，如果最终显示排版好点可能会减少许多空白行，但是有些空白行完全是主观强行想要的。
还有就是空白字符，MD 中许多地方需要在标记符号后专门敲出一个空白字符，但是有些却不能有空白字符，比如此行：斜体字不能加空白字符。
另外就是本篇文章， 看了下貌似 码云上的 Solo 直接没有开 issue ，github 上开了，那么此时就有 2 个地方在做同样这件事，或许 github 上许多是非社区用户发起，社区的这篇非社区用户稀少吧，有点乱、重复，可能同时会在 2 个地方都出现针对同一问题的报告，管理也比较麻烦。
github 上的 issue 有比较好的交互、流程，社区的比较满足社区功能。不过，或许在将来社区也同时实现类似于 issue 这种模式的报告帖子功能，然后关闭或引导其他地方的 issue 提交用户到社区来。
这样做的好处：
Solo 和 Pipe 的定位是 B3log 分布式社区的博客端节点，并不是通常意义上的独立博客，所以账号体系需要进行统一，否则带来的问题会很多，这也是一路下来探索的，具体经历细节请看这里。
你提到的解决方案在 Solo v3 之前一直就是这样做的，经过长时间验证效果并不理想：
这两个问题是矛盾的，所以为了解决它需要将账号在 B3log 网络中进行唯一化。一开始的设计方案是通过公私钥（类似区块链的钱包原理），但这个方案在现阶段过于复杂，用户使用门槛有点高所以暂时放弃了。公私钥的方案在星火项目里进行过测试验证，技术上应该没问题，以后鱼塘项目可能会采用这个方案。
所以再次重申一下，Solo 和 Pipe 是 B3log 分布式社区的博客端节点。举个最容易理解的例子，这就好比某些厂商的软件，没有这个厂商的账号是用不了的。打通其他网络的方案是在博客端或者社区端接入其他网络的账号，目前已经在黑客派上接入 GitHub 登录（可在账号设置中绑定），Solo 可通过 GitHub token 来将文章同步到自己的仓库，避免整个 B3log 网络过度封闭内卷。
最后，希望目前加入到 B3log 的用户是认可这个设计的，如果不认可的话其实就没必要加入使用了，节省自己时间同时也能保护 B3log。当然，不排除以后设计还会有所变化，欢迎参与思考讨论，谢谢。