使用微博RestAPI一直存在一条人为的限制，就是必须要在文章末尾添加一个验证链接。

比如你发微博“这是我的第一条微博。”，用微博RestAPI是没法直接发的，必须发成“这是我的第一条微博。https://poster.parussoft.com/index.html”。

如果你不加上这个链接，微博服务器就会提示错误，不让发微博。

这个链接对于用户其实是没有意义的。并且直接加在微博末尾，就会有人点击它，然后奇怪为什么会有一个跟内容没什么关系的链接在那里。

为了尽量减少用户点击这个链接的可能，咕唧从2018年3月底发布的1.7.13版开始，增加了一个折叠隐藏该链接的功能。利用的原理是，微博官方微博网页版和客户端，会在内容过长时，自动折叠微博，而咕唧会在字数允许的情况下，添加空行，将该链接隐藏起来。

但是这个功能存在限制，因为只有官方的网页版和客户端才有折叠的功能。其它第三方的客户端，官方的html5版以及国际版，都不具备折叠的功能。在这些微博客户端中，咕唧发布的微博就会变得特别长。因此，时不时的，我就会收到评论或者私信，问为什么我发的微博会那么长？

咕唧2决定彻底解决这个问题

我的思路是，既然这个链接必不可少，那么我可以将其从无用的链接，转换为有用的链接。这样用户点击了也不会显得突兀。类似这样的查询“https://poster.parussoft.com/jumping.php?query_string”。

思路1

思路确定好之后，我发现，生成的链接必须经过服务器的处理才可以。那么就有两个思路：

1. 直接保存对应的html文件到磁盘。（这样占用磁盘较多）
2. 将查询条件和结果保存的数据库，动态查询。（这样占用磁盘少，但是CPU占用高。因此还需要缓存查询结果。）

我觉得第2条更好。这样就需要在服务器端使用PHP和Sqlite。思路总结完，我在服务器远程安装好PHP和Sqlite3之后，就睡觉了。

思路2

第二天，开始继续前一天的工作。我发现微博账户的用户页，其实是需要和其它链接分开的。因为微博账户的用户页，可以直接根据微博用户的id自动生成。我又想到，既然可以自动生成，那么该项就不用保存到数据库，直接通过id生成并跳转就可以了。

之后，我又想到，链接的跳转也是同样的道理，可以直接将链接做为查询的字段，这样就能直接跳转了。

这样一来，思路1中的PHP、数据库、缓存就都不需要了，服务器端只需要写一个能判断查询类型并生成跳转链接的Javascript网页就全搞定。

结论

不同的思路，需要的工作量完全不同。多思考，比埋头苦干，效率更高。