练手小工具 之 纯文本跨设备传输

练手项目很难选，也很难参考，毕竟每个人的技术栈、兴趣、目的、需求等等都有巨大的差异。

比如目的，如果专注于提升技术，就会选择难度较大的项目；如果专注于赚钱，就要多花精力在平面设计、竞品调查研究、宣传上。而本文提出的例子，目的主要是满足自己的需求以及为空闲时间提供一些既有趣又没有心理压力的任务。

需求与灵感

现在我有一个需求：需要在不同的电脑、手机之间交换纯文本（一个短字符串），包括 Windows, MacOS, Linux, iOS, Andriod, 其中包括无图形界面的服务器。

做一个满足这个需求的小工具，对于我来说最简单的就是做一个网站，由于我的需求只是传输很短的纯文本，并且是一个自用的工具，因此不需要担心传输速度、流量、服务器负荷等问题。

小项目，多花样

最基本的玩法是做一个网站，不同设备通过访问网页进行文本的黏贴、复制。

但玩法绝非止步于此，比如：

• 无图形界面的服务器，可以做一个 CLI 工具来收发文本
• iOS 可以利用“快捷指令”来接收文本到剪贴板、发送剪贴板内容到服务器
• Windows 可以使用 AutoHotkey 操作剪贴板，一个快捷键就能接收文本到剪贴板或发送到服务器
• 做手机 App
• 增加对图片、文件的支持
• 改成多用户系统，开放注册
• 复制代码片段文本转换成图片
• 复制文字后触发语音朗读
• …… 等等

不是说这些全都做，而是可以想到很多，然后挑一些来做。我建议先做一两个简单的功能，后续再慢慢进化。

总设计（需求与灵感的细化、具体化）

对于我来说，总设计是最关键、最难，通常也是要花最多时间的一步。

总设计的本质是做选择。一个表面简单的需求背后通常隐藏在大量选择，比如：

• 做成单用户还是多用户系统？
• 只能传输文本吗，要不要提供传输图片或文件的功能？
• 每条消息的上限是多少字？
• 全部消息要长期保存吗，要做搜索功能吗？
• 要做 CLI 吗，网页版的功能与 CLI 有什么区别？
• 是完全公开还是要密码登入? 使用 CLI 时如何输入密码（每次输入还是缓存在哪里）？
• 每条消息可单独编辑吗，还是不允许编辑只能删除？

…… 等等。这只是一个极简单的小工具，要思考的东西算很少了，项目稍大一点要思考的因素就会指数式增长。

有人习惯先做，一边做一边想一边改，这个方法完全没有问题。我的习惯是先总体上尽量多想，让脑子里“成品”的形象越来越清晰，清晰到一定程度之后我才开始写代码。

我的决策

目前，我想象中的这个小工具应具备以下特性：

• 只能收发纯文本
• 上限 1000 条，超过上限则自动删除最早的消息
• 每条消息上限 1024 bytes
• 每条消息均可单独编辑、删除、复制
• 可在线添加新消息
• 主密码的唯一功能是生成 key, 其他操作需要使用 key
• 每个 key 的有效期是 30 天
• 网页提供搜索功能, CLI 提供受限制的搜索功能（向 CLI 返回搜索结果的上限是 10 条）
• 只检查是否与上一条消息内容相同，不检查历史消息
• 消息列表不分页，但只截取开头，需要点击才加载全文

如果是你来做这个小工具，你会如何决策呢？每个人有不同的决策，这正是做小工具的乐趣之一。

技术选型

由于我很懒，也怕麻烦，技术实力也差，因此我会尽量选择简单、原始、直观（思维负担低）的技术栈。

比如前端我就用 JQuery, 简单到极致。我也用过 React 和 Vue, 结果发现对于一个简单的界面来说, JQuery/React/Vue 都差不多！

React/Vue 做复杂界面有优势，但对于简单界面，实在没有带来特别明显的好处。JQuery 的好处是比较轻，而且可以彻底抛弃 npm, 这使得前端构建省了很多事。

当然，这是因为我不太爱玩前端，对于爱玩前端的人来说选择就完全不一样了，这需要根据自己的喜好、技术背景、目的来选择。

后端我选择 Go, 因为用 Go 做的小工具（小网站）是最容易发布的, 现在做项目通常都会使用 GitHub 之类的代码仓库，而仓库地址就是 Go 项目的发布渠道，完全不需要额外的操作，而且又能打包为一个免安装的可执行文件。

再加上 Go 占用的资源极少，我只需要一个最低配置的 VPS 就能同时运行一大堆小工具。

容易发布 /部署、运行资源少、编译速度快、web 框架很轻但也够用，同时具备这几大优点的语言也只有 Go 了吧？（当然，如果做大项目, Go 的优势就不明显了，主流语言能够成为主流，各有各的好。）

最后

这个小项目我现在开始做，后续想到什么再补充吧。