@liuzhihang 你是通过开放 api 还是模拟登录写入数据？大部分情况都不会改接口。但不排除可能会有字段变更的情况。一版开放 api 会考虑向后兼容性，因为可能已经有程序调用了开放 api

@inroading 不一样的概念。IE6 在 IT 群体里使用率非常低。而后端的兼容性，老系统的使用率太高了。举个例子，现在国内主流的 linux 系统之 centos7，其默认的 php 版本是 5.4 。这块用户还是不能直接放弃。

有一篇老文 产品经理文档神器-showdoc https://www.jianshu.com/p/71becd55681b

推荐 showdoc，一开始简单好用，深入后使用，功能也强大得满足各种需求。https://www.showdoc.com.cn ，而且开源持续更新。

@crownzzz 知否会一直维护的，让其一直可用（主要是我本人也在用）。至于功能更新，看情况吧。目前我觉得还是挺够用了。所以没怎么花时间做新功能。

读取环境变量更好一点吧。

私有化部署不是很有必要一定上 k8s 太重了。如果是你们提供公有服务的话，使用 k8s 就十分合适。

而且我看了下，无论是 issue 还是这里评论，都非常多人建议分开处理。我不明白坚持不分开的理由是什么。

强烈建议把软件项目和资料汇总项目分开。资料汇总项目是有它的价值，但是不同维度的比较会明显挤压软件项目。

这是好事，我非常开心看到这样的情况发生。它证明编程发展得越来越成熟了，不需要总是在基础设施这个问题上反复造轮子。编程语言本应该成为稳定的下层基础设施，为上层提供更好的服务。

我上面说的不严格。应该说正常的项目开发里 merger 都是自动合并，极少需要手动解决冲突。

看到附言说“关键点是使用 git 要花团队更多时间，而不是会不会用 git 的问题”，原谅我不自觉发出了笑声。就是因为你们不会规范使用版本工具，所以才花更多时间。
我觉得你们的分工问题应该是重点关注的问题。正常的项目开发里，大家负责的模块是分开的。不应该会导致那么多 merger 。甚至应该做到极少的 merger 。像你说的，无论 svn 还是 git 都需要 merger，那估计是不正常了。分工模式可以再探索下。

内部团队用的话其实 svn 也不差。git 是一种更普适的适合各种规模的版本管理。比如开源给全世界不认识的人看以及协作。
另外你的问题不是版本管理软件的问题，纯属是你们自身使用不当。

保存 key 合适。这样解耦。

一个打算认真发展的项目是不会用的。因为那种等于暴露了用户数据的同时强依赖了一个第三方服务，风险不可控。即使像 authing，大企业使用也是使用私有部署的，不会把自己的用户体系强依赖他们。

如果不追求开源，也可以尝试 showdoc 官方服务 https://www.showdoc.com.cn/

如果说要追求开源，那非常推荐 showdoc https://github.com/star7th/showdoc

内网不用。公网需要。就这么简单。

想起了这个帖子，过来回复一下我为什么当初想买但后面又打消想法的原因。
你这个插件信息完成度很低，甚至简介，用户体验指引都马马虎虎，不知道怎么累积到 10W 用户的。但我想活跃度肯定非常非常低。随着谷歌官方出了二维码相关的功能，这个插件基本宣告死亡的。哪怕还有二维码插件生存空间，也是给其他更优秀的竞品拿去了。所以我觉得除了搞黑产的人外，应该很难碰到有正当需求的接手人。哪怕卖 7000 块，我都觉得很贵了，因为没有什么正当需求价值（黑产除外），而且是处于消亡中的低活跃产品。而你是否真的要卖给黑产的人，这个看你自己的产品良心吧。我是属于那种宁愿亏钱也不卖用户 /损口碑的人。如果你也能对产品负责就更好了。
上面的大部分人说流量价值肯定远超 1000 刀的是因为不了解具体情况。而你心里也明白这个流量价值很低，不然你也不会长期对维护这个东西不上心了。说太忙没时间维护往往是借口，大多数情况是自己心里觉得它的付出和回报不成正比。