我比闹钟早醒了十分钟。不是因为兴奋。是因为脑子已经在转了。
昨晚睡前查了一圈SheetJS的文档。JSON转Excel不像转CSV——CSV是纯文本,逗号隔一下就能拼出来;Excel是二进制格式,.xlsx本质上是个zip压缩包,里面装着十几个XML文件。手写解析不可能,得用库。
前世我压根没做过json to excel这个页面。当时看到展示词里有这个词,心里冒出来的念头是"差不多得了,json to csv已经覆盖了"。然后就跳过了。
差不多。
这两个字在出海圈里是毒药。
用户搜"json to excel",他要的是.xlsx文件,能双击用Excel打开、格式齐整的那种。你给他.csv,他得自己改后缀名,还得处理中文编码问题。功能"差不多",体验差了十万八千里。
Google比我更早发现了这件事。它把我的json to csv页面展示给了搜"json to excel"的人。那些人点了进来,发现不是自己要的,又走了。
我浪费了他们的时间。也浪费了一次被满足的机会。
——
打开ChatGPT。输入需求:
“我需要一个在线JSON转Excel工具。用户粘贴JSON到文本框,点击按钮,下载.xlsx文件。需要处理嵌套JSON的扁平化,列名要可读。用SheetJS库,纯前端实现,不要后端。”
ChatGPT吐了一整套代码。React组件,import语句,flatten函数,导出函数。结构清晰,该有的都有。
复制到VS Code。装依赖。跑起来。
粘贴一段测试数据——一个简单的用户信息JSON,两层嵌套,十几个字段。
点"导出Excel"。
浏览器下载了一个.xlsx。双击打开。
能用。
列名是"name"、“email”、“address.city”、“address.zip”。
address.city。
用点号连接。技术上没错,Excel也认。但用户看到"address.city"这一列,他不会觉得这是个友好的工具。要是嵌套五层呢?first.second.third.fourth.fifth?
我回到ChatGPT:“扁平化之后的列名不要用点号连接,换成更可读的格式。比如address.city显示为’地址 城市’。”
ChatGPT改了一版。columnNaming函数里把点号替换成中文连字符。
问题是——我的站是英文站。用户是英语用户。列名里出现中文?
我又改了一版。把连字符换成" / ",address / city,phone / mobile。英文的,干净的。
再用一段更复杂的JSON测试——三层嵌套,中间夹了数组。
导出。打开Excel。
第三层那个数组字段被展开了。一个数组[“red”, “blue”, “green”]变成了三列:colors[0]、colors[1]、colors[2]。
如果数组有五十个元素呢?五十列?
这不是ChatGPT的错。是需求边界没想清楚。嵌套JSON转表格,这件事本身就没有标准答案——一个key对应一个值,简单。但一个key对应一个数组,你要怎么铺?
每个需求都是一棵树。你以为种的是灌木,挖下去发现根系比你想的深得多。
花了一个小时自己重写扁平化逻辑。数组的处理改成:简单类型数组(数字、字符串)用逗号合并到一个单元格;对象数组取前三个展开,超过的截断,最后一个单元格里标注"(more)"。
不完美。但对于一个在线工具来说,够用了。
——
下午三点。
页面基本成型了。但还有一个坑在等着。
5MB。
ChatGPT的代码在处理小文件时没问题——几百KB的JSON,秒出。但当我丢了一段3MB的测试数据进去,浏览器卡了五秒钟,然后整个标签页灰了。
崩了。
内存溢出。SheetJS在浏览器端解析大JSON再生成xlsx二进制,内存峰值能到原始数据的十倍。3MB进去,峰值可能到30MB。桌面浏览器勉强撑得住,但移动端呢?用户在手机上粘贴一段大JSON,页面直接死了。
前世我不会管这个问题。功能做出来了就行,谁会贴3MB的JSON到网页上?
今生我知道——会有人这么做的。前世在推特上见过,有人把一个API返回的完整JSON丢到格式化工具里,页面崩了,他发了条推文:“This tool is garbage. It crashed on a 2MB file.”
一百多个转发。那条推文比我做的所有站加起来流量都高。
加了一个文件大小校验。上限5MB。超过的在页面上提示:“The input is too large for browser processing. Please limit JSON to under 5MB.”
不优雅。但实用。
前端工具站的第一原则不是功能多强大,是别崩。用户打开你的页面,粘贴东西进去,页面死了——他不会回来第二次。不会给你第二次机会。
——
下午五点半。
json to excel页面上线了。
TDK:
URL: jsonprettyprint.com/json-to-excel
更新了sitemap。提交了GSC。
站点从八页变成了九页。
第九页。听起来还是个很小的数字。前世我做了二十个站,加起来上百个页面,月收入$200。页面数量从来不等于收入。
但前世那上百个页面,没有一个是展示词数据告诉我该做的。全是"我觉得这个词能做",做完发现没流量,再做下一个"我觉得"。
这一次不一样。这一个页面是Google先告诉我的——有人在搜这个词,他们看到了你的页面但没被满足。你只需要补一页。
我截了一张图。json to excel页面在浏览器里的样子。存进种树笔记。
——
顺手刷了一下GSC。
json to xml终于收录了。
第六个。
现在只剩json diff还没进来。提交状态栏还是"已发现,尚未编入索引"。json diff的代码量最大,页面体积最重,Google的蜘蛛需要多来几次。不急。
过去三天的数据:
展示次数:247。点击次数:62。平均排名:117.8。
117.8。上周是142.7。降了二十多名。从大约第14页到了第12页。
日均UV从23涨到了大约33。
不多。但方向是对的——每多一个页面,就多几个入口,展示次数就往上挪一点,排名就往前挤一点。
一棵树。多一根枝。多一根枝,多接一点阳光。
——
晚上。
打开哥飞社群。
帖子底下多了几条回复。
ID叫"出海老张"的说:“我也查了一下展示词,发现我的站被匹配到了’design template’,但我做的是’website template’。Google觉得这俩意图重叠?”
另一个叫"ken_studio"的回复:“展示词真的是宝矿。我之前做了个站,TDK全靠自己拍脑袋想,做了半年流量没起来。后来看展示词才发现Google把我的页面匹配到了一个完全没想到的词,重新优化了TDK,一个月内流量翻了一倍。”
ken_studio。这个名字前世有点印象。好像后来做了一个设计类的工具站,做得还不错。
我在他回复下面点了个赞。然后打了几个字:
“谢谢分享。看来展示词不是看一次就完的事,得定期看。”
发出去。
然后看到老张在问design template和website template到底要不要区分。我想了想,又回了一句:
“可能用户群不一样。design template更偏设计师,搜的人想要视觉模板;website template更偏开发者,搜的人想要代码骨架。如果你的站偏技术方向,website template可能更精准。”
打完之后犹豫了两秒。前世我在群里从来不会主动分析别人的问题。怕说错,怕被说"你一个新人在这里装什么"。
但ken_studio在认真分享经验,老张也在真诚提问。群里的氛围不是我想象中那种"大神说话新人闭嘴"的样子。
回车。
周叔衡没有再回复我的帖子。他的那句"你进步挺快的"挂在回复列表里,像一个路标。不是终点,只是告诉你方向没错,继续走。
——
睡前。
打开AdSense。
$0.00。
三十三个UV。一个底部广告位。没有人点。
正常。非常正常。
前世我在这个数据面前会焦虑:做了九个页面,流量也在涨,为什么还是一分钱?是不是方向错了?是不是该换个赛道?
今生我知道——33个UV,假设点击率5%,也就1.6个点击。每次点击的单价大概0.1到0.3。一天0.16到0.48。但实际点击率远到不了5%,因为底部广告位的可见度极低。大部分人用完工具就走,根本不会滚到页面底部去看广告。
广告位的位置以后要调。但这不是现在该操心的事。
先把内容做扎实。把页面铺开。把排名做上去。等日均UV过百了,再回头优化变现。
种树。别急。
——
关电脑之前,在种树笔记里新建了一个文件。
文件名:json-to-excel-实现记录.md
记了三件事。
最后加了一行:
“json to excel上线时间:2023-05-28。等待收录。”
前世这个页面我从来没做过。前世甚至连这个想法都没有——json to csv"差不多"就行了。
差不多。这两个字让我错过了一个明确的需求信号。Google把用户送到了门口,他们敲了门,我没开。
今生我开了。
第九页。一扇新门。