@seth19960929

因为要写 api 文档给团队的其他成员看。比如后端写给前端看。
如果不想手写 api 文档，可以用 runapi 来自动生成 https://www.showdoc.com.cn/runapi

@lmoon

所以我保守一点，加上了明显的国内范围限制，免得有人喷我标题党。
目前来看，这个标题还是基本符合事实的。如果连 符合事实 的标题都看不惯，只能说某些人纯属只是看不得别人好。

@iblessyou

我没有看到 这种本地启动服务的方式 比 showdoc 现在的方式 有明显的好处。

@rzdCG

showdoc 是网站为主的，基本全平台的浏览器都可访问。
你说的没有 linux ，应该指的是客户端吧。其实 showdoc 客户端也只是一个 web 打包，我统计了下使用率也没有很高，大部分用户还是直接通过 web 访问的。

@nekoneko

多谢支持

@ggp1ot2

typore 不开源，不在比较的范围内。

我起这个标题的时候，其实是调查过了的。基本符合事实。当然，为了防止翻车，我加上了“可能” 两字。
如果不符合事实，你大可找反例来反驳我，我承认我的孤落寡闻后，回去默默提高产品体验。
但是如果是符合事实的，那为什么不能把 产品的优点（颜值）拿出来做一下宣传呢。所以我起了这个标题。

@vayci

尝试发一下你认为颜值最高的国内开源文档工具来让我学习下？

@ggp1ot2

你可以尝试发一下你认为颜值最高的国内开源文档工具来让我学习下？

树莓派的最大作用是吃灰。找不到好的使用场景。

@way2explore2 @lucasji

我没太认真看。
我的意思是建议使用这种明确 return true 或者 false 的方式。这样一看就知道返回布尔值。
直接返回一个表达式的可读性并不高，我要多看一眼去确认才知道他返回的仅仅是一个布尔值还是表达式后再运行什么再返回。

即 我认为

if( 1 === 1 && 2 === 2 ){
return true ;
}else{
return false;
}

比

return 1 === 1 && 2 === 2

的可读性好 。

@way2explore2

我同意你同事的看法。

我觉得，在不影响性能的前提下，永远是 可读性 比 代码量少 重要。

我觉得，在不影响性能的前提下，永远是 可读性 比 代码量少 重要。

@zhangtest

图像搜索很多开源库。基本没有太多入门的技术门槛。要做深则很难。这东西就像训练 AI 那样，需要数据和算力。早就不是单个人就能玩好的领域了

nas 的话，像群晖这些商家不知道提供功能了没。如果没有，他们早晚会做这个功能。

大概率不能。百度和谷歌都提供识图功能，且他们的搜索范围更广。你做这个，推广都是一个问题，别说盈利了。

又是一个想白嫖劳动力的。这不是调侃，而是在陈述事实。

我想写个脚本给自己用，自动帮我接受对局，并自动选择英雄，这样我不需要在等排队的过程中总是在等。

lz 可否把 实现这个功能过程中的思路以及可能用到的文档，api 告知我一下？
可能我翻官网文档也能慢慢琢磨出来，但是因为你有经验，你如果告诉我的话，我可以省一点功夫。

总算有个人也是头疼变量命名了。

我也是头疼变量命名，所以自己开发了一个变量命名模块

https://www.aiznx.com/#/detail/varRem

不建议共享，就建议独立搞。
原因：
1 ，不同容器的依赖既然不同的话，那何必花力气去共享那一部分相同依赖？
2 ，磁盘空间不值钱，节省那边磁盘空间并不会有多少差距。至于内存消耗，你共享不共享，都一样的消耗。
3 ，若强制共享，打破了隔离性，反而会被后面增加很多维护成本。