你有没有在某个时间某个地点，对自己周而复始的人生产生过厌倦？
月黑风高的某个晚上，我在家里，无所事事地蹲着坑，听着窗外凌冽的寒风，决心要对自己的毫无意义的一生，动刀子。
可我能做什么呢？人的一生，大多碌碌无为；衣食住行，功名利禄，无非是为了让自己再看一眼明天而已。人活一辈子，总想着去建功立业，以为有人喝彩，这样的人生才有意义；却不曾想，活着本身，就已经花光了自己所有的力气。
哪怕是五陵豪杰墓，如今也再无玉簋花酒，沦为了牛马田地。再大的丰碑，再多的功绩，也赢不过人们遗忘的速度。何况我们普通人呢？
面对普通得无法言述的人生，我哪怕再努力去编造，我也没法把它拍成电影。我的人生，感动不了自己，更感动不了别人。
所以，虽然我很想对我的人生动刀子，但我能做什么？难道我能做的，就只剩等待，亦或是转身离开？
现在我觉得，可能是我想错了。我们本不必如此，人活一辈子，并不是非要在别人心中留下一道浓墨重彩，才会叫无憾的。有道是“无为而治”，我每日虽无大为，但我也有小碌，在忙着照顾自己，让自己从平顺中醒来，在安稳中睡去。
这些小事，从来都不是什么没有意义的事。它们对于我而言，就是我的基石、我人生的鳞片——它们虽然细小，但会闪光；汇在一起，它们就是我的战甲，我的功劳簿。
我的小事，对别人毫无意义？没事，我的小事，我自己关心就足够了。我要把它们一件件地捡起来，因为我不再忍心它们匆匆发生然后就被遗忘在时间里——而这，就是我对我人生中无意义的大部分所交出的最好答卷：
赋予生活琐事以意义，并记住它们。
可是如何记住它们呢？
面对我的人生，我不想仅仅为了记录我的生活，就再做一件高射炮打蚊子的事。我的人生，可不想再经一次这样的折腾。
这件事，应该是有仪式感的、是轻松的、是随手的，且不压迫、不僵化、不严肃。这些原则，不仅要体现在最终的使用体验上，也应贯穿在开发的全过程。
所以，我首先应该考察一下市面上的各种便签/清单/打卡/番茄钟/时间追踪应用？万一已经有趁手的成品，我不就不用折腾了呗？
可惜，一番体验下来，我发现市面上的这些软件统统都不能用。
虽然我的记录日常活动的想法，像极了那些freelancer使用的时间追踪（Time Tracking）或番茄钟软件，比如Hours、Toggl Track等。
但它们有些共同的问题：首先，它们要求一个事件有严格的开启和终止，但我想要的更多是一次性的打卡点；其次，它们似乎对多线程记录不太友好，而我的日常生活里，很多事可能是多线程并行的；然后，它们对于我的设想场景都over-engineered了，那些多人协作和数据分析的场景对我而言都没有必要；最后，它们鲜有支持智能手表的，只有Hours支持了苹果手表端的，但也是缺失了安卓手表端的支持——而且就算支持了，它们也只支持通过Google Play Framework的跨端连接和账号同步，这在国内的市场环境也无法施展拳脚。
此外，就算考察别的类别，比如To-Do、滴答清单这类清单或打卡软件，也会有些问题：如果不使用它们的定时任务，那每次记录就需要手动输入一次任务名称，这太累了，不轻松，对于后期的数据归集也不便；而如果使用它们的定时任务，那场景就变成了每天的定时打卡任务，这也不是我的本意——我的本意是记录，而不是让它催我做事——所以这些软件都显得过于僵化，压迫感太强了。
那，我自己开发一款应用得了呗？
到此，这成了我唯一的选择。但怎么开发，开发成什么形态呢？
我的需求是可以手表上“从从容容游刃有余”地记录我的生活小事；而且也应该支持多端接入，方便我在各种终端上都能随时记录；最后，如果数据的可管理性做到最好，对后期的数据归集与管理友好的话就更棒了。简而言之，这个应用应该具备跨端适配能力，数据库设计应该开放一点。
这一听，工作量就上来了。醒醒！我可不能再为一碟醋包一盘饺子了啊——搞太大阵仗真没必要。
既然如此，我首先想到的是使用一些LowCode平台去帮我生成一款这样的应用。毕竟现在AI横行，Cursor、Windsurf、Claude Code之流都觉得他们可以干掉程序员了。所以我也想有个工具来干掉我一下下的，这不过分吧？
听从Gemini的建议，我先试用了PandaSuite：
兴匆匆上去注册个号准备开干，却发现它不支持网页端编辑，非要下载个客户端……而且它客户端在国内的连接速度也太慢了，资源都刷新不出来……好一个“出师未捷身先死”，一怒之下，卸载，删号，好走不送。
然后，我再试试享誉全球、统治垂直市场的Adalo：
不得不说，这货就是丝滑，而且强大。和它的AI聊两句，就给我做好了后端的数据库表，然后同步做好了几个UI Screen版面给我；版面元素的设计排版，也是动动手拖拖就生成了，无需理会诸如pt和attribute这些让人头疼的破事；按钮事件和数据库表的操作逻辑也在AI的帮助下智能地实现了绑定，无需自己写SQL语句。整个体验下来，的确挺LowCode的。
大概半个小时，在Adalo上就开发出了可用的第一版了，还是挺棒的。然而等我兴致冲冲地走到Publish这一步时：
看着这个价格，我兀自瘫坐在电脑屏幕前面，感觉这时的自己就像《喜剧之王》里的张柏芝，坐在车里哭到破相。
原来这世上的LowCode，并不是LowCost的啊。人们把一件本是复杂的任务包装成一个简易化的产品所花费的成本，最终会转嫁到什么都不懂的小白头上。
或许，在这个事件中无处不在的AI，也是一样吧。计算机的世界里，哪有什么真正的智能、哪有什么真正的免费？所有白嫖到的快乐，都隐藏在了你后期调教它的时间成本，还有你看不见的训练成本和计算成本里面了而已。
我们需要的是助理（agent），但在计算机的世界里，你最多只能得到一个模板（template）。这之间的鸿沟，你要么自己跳过去，要么花钱铺过去，从来就不存在第三个选项。
难道就只能这样了吗？
故事还未结束。Adalo的收费虽然吓退了我，但它的结算页面倒是提醒了我：我或许可以直接搞一个web应用来做这件事。
说起来，Web应用应该是最通用且最繁荣（？）的应用形式了吧。无论是什么操作系统、什么终端设备，都少不了一个叫“浏览器”的App，让你可以上网；而且，当今任何流行的软件形式和产品，也没见过和HTTP完全没有关系的。
这时我突然想起来， 我的OPPO Watch X在半年前的更新中加入了官方的浏览器，体验还算不错。何不借此机会，直接开发一个Web应用，让我一次发布便可打通手表、手机和PC的接入？
这应该是我目前最快捷最省力也比较经济的做法了。这种支持跨端适配的Web应用，在现在有个时尚的名字：PWA应用（Progressive Web App，渐进式Web 应用）。它的跨端适配能力，使得它在任何平台上看起来都像是个原生的应用程序一般，故得此名。
但，若还是需要从头来开发这个PWA应用的话，工作量也还是不小。毕竟，作为一个开放的web应用，我应该有基本的认证和鉴权机制作为基础，然后我才能愉快地记录我的生活；此外，PWA所需要的跨端适配能力也不是HTML原生的特性，它需要引入一些基础库作为支持；最后，还要考虑后端数据库的兼容性和持久化等问题。
慢着——
这么说起来，我的WordPress博客，不就恰好具备上面三个条件吗？！WordPress作为一个基础特性完备的CMS内容管理系统，它本身就提供了账户系统，这天然解决了我的认证和鉴权等需求；Web页面的跨端适配问题，在WordPress提供的Elementor编辑器中也是小菜一碟，因为Elementor在设计之初就将PC/Pad/Phone三种视图的适配考虑在内；WordPress依赖的MySQL数据库也是一个麻雀虽小五脏俱全的数据库，我已无需为之操心，而且WordPress还提供了基于JSON的RESTful接口，所以操作数据库和对数据的二次开发等，都不是难题。
于是，开发一个类打卡软件的需求，最终完美地cost down成了在WordPress上开发一个页面的问题。
行文至此，想想也是可笑：我一开始在那长篇大论絮絮叨叨，搞得像要去打打杀杀开疆扩土似的，最后发现不过是开发一个博客页面的事儿。这像极了公司里面的那些繁文缛节：本来一个人三下五除二就能搞定的事儿，却因为老板们都要雨露均沾，非要整个团队之间相互制衡，所以得强行上团队分工，最后整件事就越滚越大，无休无止，变得复杂得要命；过程中老板们还会发明无数的概念和流程，来标榜自己的功劳，绕晕了投资者也绕晕了干活的。
程序员给人打工，或许天生就是很难的：风霜高洁的程序员喜欢简洁高效和永恒，换言之，就是喜欢神性多一点；但人类社会，从来都是屁股决定脑袋，人性总要占据上风的——不然就不叫人类社会了，得改名叫永恒族了。
然而，程序员无论再怎么风霜高洁，人总是要吃饭的。所以程序员们，如果某天你走到了一个艰难的十字路口，不知道要向左走还是向右走的时候，请相信我，无论你选哪一边，它都是对的。而且，如果你是一个厉害到没朋友、可以在判断题里变出个第三选项的那一种黑客，你甚至可以选择向前走。
WordPress拯救狗生？
回到WordPress上来。事先声明，WordPress并非致力于满足我这种奇葩而且小众的简易PWA应用的开发需求的。所以，我们仍需要一些魔改的操作，和一点点的代码工作量，才能让它变成我想要的样子。
我的需求很简单，也很奇葩，下面正式陈述一下我的概要设计：
- 我需要把我每天的一些重复性任务做成一个个按钮，因为事务多变，这些按钮需要比较方便地被我增删，并且改动时无需改动代码或者迭代版本；
- 每当我做了某个按钮上的任务，我就点击一下这个按钮，此时服务器会响应我的请求，在数据表里添加一行新记录，其中包括我当前完成的任务名称，和当前时间戳；
- 按钮下方，应实时显示我上一次完成这个任务的时间，和距今的时间间隔，让我可以直观判断下一次做这项任务的迫切性；
- 前端页面应该自适应地适配PC/Pad/Phone，以及最重要的，Watch。
- 因为任务多变，并且为了方便后期拓展，数据表记录的任务名称字段不能是限定值，而应该是开放的，同时，为了避免过于开放导致的不对齐，这个限定的工作应该交给前端设计，在设计按钮的时候来限制，即限制按钮不能过于随便地被修改；
- 为了提供和时间追踪软件类似的活动追踪功能，对于需要记录活动起止时间的任务，我可以拆分成两个按钮，一个按钮负责记录任务开始，一个按钮负责记录任务结束。
- 需要提供一个后台的管理界面，方便我管理/微调/追踪我的数据记录，并支持导出到excel。
明确了这些需求要点，我便可以着手实现了。
首先，在Rest API中添加自定义的端点
在我的设计里，前端按钮是通过Restful API和后端的数据库进行交互的，而且操作的是我自己定义的一个数据表。所以通过Restful接口是我最方便和自然的方式，并且WordPress默认便支持Rest API。但因为是自定义的数据表，WordPress本身并不存在对应端点，所以我需要借助一些WordPress插件来在WordPress的Rest API中添加自定义端点。
首先添加“Disable WP REST API”，来禁止未登录用户对Rest API的访问。
然后添加“Ultimate Endpoints With Rest Api”，来帮助我添加自定义的Rest API端点。需要注意的是，这个插件需要你在WordPress的PHP代码里添加hook钩子函数，然后在钩子函数里按照你的想法去操作数据库表，才能真正达到你想要的功能。
所以，为了方便管理这些魔改WordPress的代码，我还需要安装“Code Snippets”。
如图，通过Code Snippets把一段简短的钩子代码注入到WordPress之后，Rest API部分便告一段落。
然后，在WordPress中添加一个新页面
完成了基建的魔改后，我便需要完成整个前端页面的工作，这在WordPress中就是添加一个新页面的事。
因为我对界面的美观没什么要求，而且我需要在手表上打开，所以我希望它越简单越好。这能减少内存的占用，提升渲染的速度。
在Elementor编辑器里，库库一顿操作，我便得到了下图的一版页面：
大家先忽略这些让人匪夷所思的按钮名称，这里有几个很有意思的点：
- 在Elementor中，页面元素对终端的适配不仅体现在flex layout的弹性适配上，还体现在按钮大小等静态属性上。在Elementor中，大部分的元素属性都可以对PC/Pad/Phone三个终端进行分别的设置，以达到更好的适配效果。
- 也就是说，同一个按钮，在PC/Pad/Phone三个终端上，大小可以是不一样的。正是因为有精细到这个颗粒度层次的适配能力，WordPress页面才有媲美PWA应用的谈资。
- shortcode是WordPress页面中一项让人兴奋的功能特性。引入了shortcode代码块以后，WordPress页面也就升级成了动态页面，和一般的博客页面终于有了根本的区别。
- 页面中添加了shortcode代码块以后，页面不再所见即所得，该块所显示的内容，将在页面加载时，由后台对应的钩子函数实时返回的结果来决定。如此，我便能实现前面需求中提到的“实时显示我上一次完成这个任务的时间，和距今的时间间隔”。
- 前面需求中也提到了“这些按钮需要比较方便地被我增删，而无需改动代码或者迭代版本”。所以为了方便我改动按钮，我使用了Flexbox容器来封装按钮和shortcode代码块这两者，然后把这些Flexbox容器放入一个网格容器中来排列。
- 如此，我需要增加一个按钮时，我只需复制前一个Flexbox容器即可；而需要删除一个按钮时，同理删除掉对应的Flexbox容器就可以；重新排列这些按钮，也只需要拖动这些Flexbox容器即可，弹性的布局会将它们自动重排。在Elementor中，对这些高级前端页面元素的编辑都是很方便的。
- 此外，任务的名称是运行时在前端按钮的Rest API URL中指定，所以要加入新任务时，直接改前端按钮链接即可，无需改动后端代码或者迭代版本。
完成这些以后，我还需要为这些shortcode代码块在WordPress中添加钩子函数，它们才能工作。同理，在Code Snippets中添加下方代码即可：
最后，不要忘了为该页面添加一个密码，毕竟这个页面的地址是全网公开的，要想避免非法访问，我们唯有使用WordPress本身为页面提供的密码保护功能。
见证奇迹的时刻？
到这就完事了？是的，到这里就完事了！
虽然前面我越过了数据表的设计，但这个几乎忽略不计，因为我就使用了一个简单表，该表仅包含了“记录号、任务名称、时间戳”这三个字段，简单到我都再多说一个字都属于矫情。话虽如此，大家还是记得设置一下主键、唯一约束、自增等什么的，数据库设计的自我修养还是不能忘滴。
接下来，让我们先看看它在手表上运行的样子吧！
这是它在PC上的样子：
- 首先，可以看到，页面在手表上的显示，是不同于在PC上的三列排列的，而是变成了两列排列。这展示了它的跨端适配效果。
- 其次，按钮下方的文字，也不再是页面设计时显示的shortcode代码了，取而代之的是实时推送的数据表查询结果。这体验，是妥妥的PWA没跑了。
- 然后，在我点击按钮的时候，Rest API也会给我返回一个json结果。并且，得益于Rest API本身的范式，每个层级的出错都会有详尽提示。所以互动体验以及调试体验这块也轻松拿捏了。
- 最后，别看这套交互操作才短短几秒，背后已经走完了一整套完备的产品级的认证和鉴权流程：你需要输入密码，才能看到这个页面；在请求Rest API之前，你需要先登录网站，否则无权访问Rest API的端点。有道是“你的岁月静好，实则是无数人的负重前行”，这套认证和鉴权机制在WordPress上丝滑到你甚至无需引入和关心，它自然而然地就为你铺好了路，并把潜在的危险拒于千里之外。
至于我前面说的“后台的管理界面”？太巧了，咱还能用现成的，就是WordPress配套的phpMyAdmin：
phpMyAdmin作为一款成熟的MySQL数据库交互界面，我想浏览/排序/筛选/查找/编辑/导出任意数据，都是随手的事。
至此，我心心念念的手表端类打卡应用，终于开发完毕。从头到尾，也就花了一个晚上的时间。没有敲多少代码，也没有做多少编译和构建工作，这事儿竟然，就完成了。
后话
你或许会说，这么简单的一个小东西，值得那么长篇大论一番吗？
于我而言，它麻雀虽小，五脏俱全，而且延伸意义远大于本身意义，非常值得掰扯一下。
在我看来，一方面，它不仅LowCode，还LowCost，而且是金钱成本、人力成本和时间成本的全方位的LowCost。
另一方面，它也不是只有LowCost，在开发体验、IDE设计体验、调试体验、使用体验、UI质感、跨端能力等各个维度，也是做到及格线以上的。
更有意思的是，如此优胜的一个成品，竟然是powered by一个老牌而且小众的软件框架，一个来自上古Web 1.0 时代的老掉牙产品，WordPress。
Cursor、Windsurf、Claude Code……Adalo、PandaSuite、Android Studio……不管是不是一个赛道的，在老大哥面前，竟面面相觑，气场全都败了。
我一开始真的不是想要这样的结果的。我本来只是想找一个契机，通过一个小众轻应用的开发，来横评一波这些新生代开发平台/框架的。就算再不济，我觉得也是回落到Android Studio上的吧？
没想到啊，最终竟被WordPress这个黑马杀了个回马抢，拔去了头筹。
仍有一些地方需要改进的。
比如，点击按钮后直接打开一个json页面似乎不够美观。应该使用ajax的方式，不用新开页面，直接原地执行并更新shortcode区域，并辅以临时弹窗来显示执行结果，这样是最好的。
但因为Elementor官方不支持ajax，这个需要魔改WordPress才能做到，待后期再弄吧。
有人可能会说，我能很快很轻松地做完，是因为“我站在了巨人的基建上”。
的确，我在开始之初，就已经有了稳健的WordPress网站作为基建。对于一个手头上没有WordPress网站的人来说，把WordPress搭起来就够费劲了，所以其实要做的工作还是很多的。
这点我不能完全反对。但我想说的是，现在的云主机，基本都为会你提供一键建站的方案，而且基本都有WordPress可供选择。所以，哪怕从头开始，你需要做的也不多，就是充钱，点开，然后你就和我站在一个起跑线了。
再说了，现在的云主机多便宜啊，总不至于像Adalo一样，我随便点几下生成的一个水得不行的应用方案，都要收我两百多块钱一个月吧。想着自己能剩下这么多钱，我噗呲一下笑出声来。退一万步，咱在本地用手头上的Linux甚至WSL搭一个内网WordPress，也能即刻出发不是？
自己动手，丰衣足食，总是没错的。
行文到最后，我仍有两叹。
第一叹，是叹我竟然无法给我这么一个需求、这么一款应用，起个恰当的名字：
它不是打卡软件（没有周期性提醒的压迫），不是番茄钟软件（不关注专注时段），不是任务清单软件（不聚焦新任务），也不是便签软件（不提供自由记录）。它只聚焦于有限的可随意调整的日常任务子集，提供松散耦合的记录功能和极快速的打卡奖励系统，并提供最温柔、最非侵入式的倒计时提醒。
它的介入程度，小到甚至我忘记打卡也没事；它接入的便利程度，沉浸到在手表上就能操作；它提供的奖励快感，不仅有短期的点击快感，也有长期的数据统筹和分析快感。也就是说，它带给我的负面影响几乎为零，但带给我的正向引导却是巨大的。
所以，它和目前市面上的所有软件都是那么的不同，以至于我没有办法用一个名字概括它。
第二叹，是叹我设计它，竟不是为了把我从日常琐事中解脱出来，而是为了把我摁回去：
可以说，我是秉承着“打不过就加入”的原则：既然我无法从这些周期性的日常琐事中抽身，那我便给自己设计一个奖励系统，去督促我去做完这些事，并从打卡的爽点中重新获得久违的快感。
这太不宅男了，这太不AI了，我离经叛道得都有点被自己吓到了——这可是按律当斩的啊！
列在这个应用上面的所有任务，都是我每天不想做但又不得不做的事情。因为不想做，以前的我总是拖到最后一刻才做，做完了也只会徒增“时间又浪费了”之感。是的，我对日常琐事的厌恶，已经到了病态的，连吃饭睡觉上厕所，都觉得是浪费人生的地步了。
这太可怕了，我如果不加改变，我将毁灭在不久的将来。而且，最让我绝望的是，在这条人生道路上，没有一个人能帮我；甚至我寄予厚望的软件商店，纵使有千千万万的软件，也都找不出一个能解救我的。
一方面，别人也帮不上忙；另一方面，饭得自己吃，觉得自己睡，路还是得自己一个人走。说到底，我想去自己做，我想要挤出空去做，我想要怀着感恩的心态去做，我还想在做完之后，能获得那种久违的仪式感和沁入心脾的满足感。
俗话说得好，既然结局已定，那过程就显得尤为重要。好好生活，好好吃饭。人生小事，都是大事。
然而，我的人生，已经无法好好地，自然而然地，去吃饭睡觉了。
所以，我急需一个旋转不倒的陀螺作为我的心理锚点，才能继续下去。所以，我无法再逃避，我唯有踏出这一步，去找到一种妥帖的办法，去直面人生所有的无意义，我才有望获得解脱。
而最好的、最赤诚的直面，应该就只剩记录本身了吧？！
不管是不是，我都唯有努力让自己相信，是！！
所以，记录人生琐事这件事，说小了，是为了有趣；说大了，是为了自救。而且，最重要的是，既然“过程显得尤为重要”，那从闭环性、自描述性、和文学呼应的角度，我寻找和开发这个应用的过程本身，也应该是轻松和优雅的、得是有仪式感和满足感的。
否则，这个应用就算完成了，我的人生也还是会倒地不起，因为我无法让自己相信，人生仍存有轻松愉快的事情。就像梅尔的陀螺，转得再久，也会倒下。
而如今，我庆幸我做到了，不管是吃饭睡觉，还是记录吃饭睡觉的方式，亦或是完成这件事的过程本身，我都做到了。这个小东西，它就是我的陀螺，我人生的fixation target。
自从有了这个小东西，我感觉活在世上，终不再是徒增年岁而已。那些最磨人的最琐屑的饮食起居和家头细务，至此摇身一变，变成了固化我人生画像的一簇簇点云，而不再是占满我的人生后便徒然消失在时间长河里的渣滓；当我回首时，在导出的一个个跌宕起伏的Excel图表中，它们也变成了一个个远近高低各不同的音符，演奏出一曲独属于我的人生交响曲。
甚至有了它，我的OPPO Watch X也不再是一块漂亮的赔钱货，而是成了我的生产力工具！所以它带给我的转变真是方方面面而且优雅的，有一种“能感觉到这事是做对了”的正反馈感。
当然了，从读者的角度来看，单靠这么一个小应用，就谈可以记录人生，也未免太儿戏了。
你说得对，所以别的重要的人生大事，我还有拍照、录像、OneNote、思维导图等方式来记录。但这些手段应对的都是我人生中那些趋之若鹜的大事，在此之前，我一直没有一个趁手的应用来专门应付我人生中这些避之若浼的小事。至此，这最后一块图终于拼上了。
不过，我的人生，你又何必关心呢？
在最后的最后，我们还是聊聊你在意的key takeaways吧。
下方给大家做了一个省流版表格，给大家盘盘这些开发路径的优劣：
| 对比项 | Cursor、Windsurf、Claude Code | Adalo、PandaSuite | Android Studio、Visual Studio | PWA |
| 本质概述 | 本质上仍是超级补全，顶多外加一个订制的Editor。 不改变构建环境。 | 本质上是官方构建环境的第三方增强版。 主要是整合构建链路和AI的引入。 卖点无外乎都是达到LowCode效果，但运行效率存疑。 | 官方的构建环境，基本但全面。 原生应用，受制于平台。 | 没有固定的构建环境，Web即所有。 可能是软件平台中唯一的硬通货，堪称平台界的Java。 |
| 支持平台 | N/A | N/A | 受制于厂商 | 通杀 |
| 上手丝滑度 | 谁用谁知道 | 谁用谁知道 | 谁用谁知道 | 谁用谁知道 |
| 对AI的支持 | 原生 | 原生 | 通过插件，你也可引入AI特性，搭建你自己的构建环境。 | 向下兼容前面三者，所以全看你想不想用 |
| 构建环境的轻重 | 视实际而定 | N/A | 基本都太重了 | 可轻可重，主要看借助的web框架 |
| 白盒性 | 视实际而定 | N/A | 编译器、目标机器码等部分都不够白盒 | 编译执行，全程白盒 |
| 可调试性 | 视实际而定 | ？？它们可不敢劳烦你干这事…… | 较好，支持打桩调试和联机调试，但调试和执行分离 | 很好，支持打桩调试和联机调试，而且调试和执行不分离 |
| 适用用户 | 小白和勤快人 | 小白和懒人 | 高性能或胖客户端用户 | 低性能或瘦客户端用户 |
| 企业级支持 | 不改变底层构建方式，视底层而定 | 不改变底层构建方式，视底层而定 | 通常额外借助git-like套件实现分布式开发支持和版本管理 | 有些web框架早期会自己集成版本管理，但现在全民拥抱git-like套件，它们也不能免俗 |