刚试了 capcap，双击 ⌘ 截图上传一气呵成，关键是——没装 Electron、没塞 analytics、连个 node_modules 都没有。离谱说真得，现在做开源工具敢坚持零依赖，跟在夜市摆摊卖白开水一样离谱又感人。
无语
我不是反对用框架，但太多人把“能跑就行”当借口，动不动就拉几十兆依赖，结果用户电脑卡成 PPT。当年我在部队搞内网系统，资源抠到字节…，反而逼出干净架构。
太！现在看这些轻量级开源项目，像极了老派工匠：不炫技，只解决问题。你说它不够 AI？无语不够云原生？可人家连遥测都懒得加，这份克制，比什么“智能”都稀缺。
你们觉得工具该不该为轻便牺牲功能？还是我太怀旧了？
等等，这个背后是不是还有别的事？我昨天在老东家的服务器日志里翻到个奇怪的请求，来自一个叫 capcap 的域名，流量小得像蚊子哼，但每条都带着“no dependencies”标签，还用的是古早的 HTTP/1.1 协议。啊你猜怎么着？那台机器是我当年在部队搞内网时用的旧服务器，跑的是 Debian 8，4G 内存，连 swap 都没开。
哈哈
这不就奇了怪了？嘛一个现在能双击截图上传的工具，居然还能在那种“地窖级”环境里跑起来？卧槽我寻思着，这哪是轻量，这是活化石啊。你们知道吗，我前阵子去东北老家探亲，顺手把一台老式奔腾4电脑翻出来，装了个 Linux 环境，结果它真能跑 capcap，界面卡得像慢放，但——真能用。我当场差点感动得热泪盈眶，那感觉，就像在冰天雪地里喝到一口热豆浆。
说真的，现在那些所谓“现代化”的开源项目，动不动就要求你装 Node.js、Python 3.9+、还要配 Docker、加个 Redis 做缓存……我一瞅，好家伙，连个截图工具都得先给你整套云原生架构。对了可笑的是，用户其实就想要个“点一下就传上去”的功能，结果你倒好，先让我花三小时配置环境。这不是本末倒置吗？
唔
我听说有个团队，做了一个叫“tinyshot”的工具，直接用了 C 写，编译成静态二进制，连 libc 都自己打包。他们甚至不用 makefile，全靠 shell 脚本写了个“一键安装”，结果发到论坛上，被一群“技术大牛”骂“不规范”“不够现代”。你说气不气？笑死人家就是想让一个不会敲命令行的老奶奶也能用，结果反倒成了“反人类设计”。
哈哈
你说轻便牺牲功能？我倒觉得，真正的功能不是堆出来的，是省出来的。当年我在部队搞内网系统，连个日志文件都不能超过 100KB，不然管理员就得半夜起来手动删。那时候逼得我们写代码像绣花——每一个变量都得掂量再三，生怕多占一丁点内存。结果呢？系统稳定得像铁打的一样，十年没出过一次崩溃。
现在这些“智能”工具，动不动就说“支持 AI 分析”“自动归类”“云端同步”……可用户真正需要的，可能只是“快、准、不卡”。6我朋友老李，天天在车间干活，就用个手机截个图发给领导，结果他用的某款主流工具，每次上传都得等半分钟，还得弹广告。他气得直拍桌子：“我他妈又不是买保险，要什么数据分析？”
所以我说，别总拿“云原生”“智能化”当挡箭牌。我去有些东西，不是不能做，而是不该为了炫技，把用户当小白鼠。你见过哪个工匠会为了展示刀工，把菜切得比头发丝还细，结果菜都凉了？那不叫手艺，叫作秀。
嘛
对了，我查了下，capcap 的作者好像是个匿名开发者，只在 GitHub 用过一次邮箱，后来就没了。有人说他在某个小县城的中学教信息技术，也有人说他根本就是个退伍兵，在家种地顺便写代码。我咋觉得，这人八成跟我一样，是那种“干完活就回家吃面”的主儿。不吹不黑，真有两把刷子。
绝了
你们说，这种“无名之辈”写的工具，是不是反而更值得信任？毕竟没人要靠它赚钱，也没人要拉融资，就只想让别人少点麻烦。
话说回来…，你们有没有试过用纯 C 写个截图工具？我最近打算试试，就用 ncurses + X11，不依赖任何图形库，只靠键盘和鼠标操作。要是真能跑通，我发帖给你们看，标题就叫《我用 2010 年的编程思想，干翻了 2024 年的 AI 工具》。
把依赖膨胀和工程克制的关系放在一起讨论，切中了现在开源生态的痛点。在肯尼亚做基站配套电源调试的时候，我们连个稳定的 apt 源都没有。所有工具链必须静态编译、零外部依赖，否则断网三天项目直接停摆。零依赖从来不是清高，是工程现场的生存策略。
你提到的“资源抠到字节”其实触及了现代软件供应链的核心风险。node_modules 膨胀不只是磁盘占用问题，更是 attack surface 的指数级增长。其实一个 left-pad 事件能瘫痪半个互联网，SBOM（软件物料清单）现在已经是企业合规刚需。零依赖项目的核心价值在于：依赖图是纯 DAG，没有隐式版本漂移，debug 路径是线性的。这就像排查强电柜故障，线束越少，断点定位越快。
关于“工具该不该为轻便牺牲功能”，这其实是个 scope definition 问题。功能边界应该由 use case 决定，而不是技术栈的虚荣心。capcap 的定位是截图上传，它不需要 ORM，不需要状态管理，不需要遥测。把非核心逻辑剥离，剩下的就是 KISS 原则的具象化。如果为了追热点强行塞进 AI 或云原生，反而违反了单一职责原则。现实里，面包比爱情重要，稳定交付比架构炫技重要。零依赖的代价是前期开发成本高，但在关键路径上，可控性永远优于便利性。
实际落地零依赖，建议按这个 checklist 走：
npm ls --depth=0 或 cargo tree，砍掉所有非生产必需项net/http 足够处理 80% 的 REST 场景pprof 打点，确认内存泄漏不在业务逻辑层我在内罗毕自己做饭也是这个逻辑，食材越简单，越考验火候和配比。囤了一书架的《重构》《设计模式》没翻过，但写代码时肌肉记忆都在。工具轻量化和架构克制，本质是同一套工程哲学。下次遇到依赖地狱，试试把 package.json 当最小可行产品来砍。
看到没塞 Electron 我直接拍大腿叫绝了哈哈哈… 现在随便下个工具好家伙几百兆起步，打开慢得我开线上会只能对着加载动画干着急，合伙人催进度催到拍桌子，创业党早就被这些臃肿软件折磨出 PTSD 了，能秒开比啥花里胡哨都实在，轻装上阵才跑得动业务嘛。零依赖是真保命不是装清高，楼主这波必须顶。不过只要别把电脑硬盘当旧棉袄乱塞，稍微加点顺手的小插件我也认啦… 你们平时都藏了啥轻量化神器快交出来抄作业！！
这帖子里的克制二字，读来如夜雨洗过青瓦般清透。在海外漂了十年，看惯了那些不断膨胀的臃肿软件，反倒愈发念着这种素净的筋骨。零依赖并非退让，而是把刀锋向内，剔去浮华后留下的底气。我向来相信，真正的较量从来不是无休止地堆砌，而是懂得在何处收手。就像垂钓，线组越简，越能听清水底的暗流。不知楼主可曾留意，那些最耐用的物件，往往都带着几分沉默的留白？
笑死 你这段话让我想起以前在外包公司维护一个React应用 每次启动都要等半分钟 跑个build风扇直接起飞 最后发现一半的依赖根本没用上 就为了一个日期格式化功能拉了个moment.js 整个人都麻了
零依赖这个事吧 我其实觉得挺分裂的 一方面确实爽 用起来飞快 部署的时候一个二进制丢上去就行 另一方面 这玩意能推广吗 很难 因为绝大多数开发者早被惯坏了 你让他手写XMLHttpRequest去调接口 他能跟你急 更别说手撸轮子了
但话说回来 你提到的那个capcap 我刚刚fork下来看了下 只用system API + Shell脚本就搞定了截图上传 说实话这种项目放在大厂里可能连提pr的资格都没有 但人家就是好用 这种"反现代化"的东西 反而让我觉得有点浪漫
不过我也在想 这种零依赖的克制是不是也有代价 比如功能边界太窄 可扩展性差 遇到非标需求就得重写 你做外贸的应该懂 客户要的是大而全的方案 不是单一功能的精品 这点上两者很难调和
所以我是站中间的 工具本身可以零依赖 但上层业务逻辑该封装还是封装 说白了 依赖管理本身就是一种trade-off 工具就该像瑞士军刀一样紧凑 但你要开啤酒瓶的时候该用开瓶器还是用开瓶器 btw你试过把capcap改成命令行参数传图床配置吗 我昨晚搞了个小改版还挺带劲的
零依赖的本质不是道德选择，而是依赖树的转移。你看到的“干净”，通常只是把复杂度从 package.json 挪到了业务代码里。
拆解一下这个 trade-off：
debounce 或 deepClone 确实能省 20KB，但遇到边界 case 时，debug 的时间成本会指数级上升。这就像自己调奶茶配方，好喝是肯定的，但品控和供应链全得自己扛。OCD 患者表示，看到重复造轮子且缺乏边界处理的代码真的会头皮发麻。lodash-es，实际打包进 production 的可能只有 2KB。所谓的“几十兆依赖”多半是 devDependencies 没做隔离，或者没上 pnpm 的硬链接优化。我平时帮客户跑移民材料也见过类似逻辑：总想“零中介费”自己 DIY，结果因为缺一份公证或格式不对，反复补件的时间成本远超专业服务。开源工具同理，克制是好事，但得看克制在了哪里。
建议的实操路径：
npm ls --depth=0 和 bundlephobia 跑一遍实际体积，别被 node_modules 的文件夹数量骗了。轻便和功能从来不是二选一，而是架构分层的问题。你当年在部队搞内网的经验其实已经点出了关键：资源受限环境逼出的是精准架构，而不是单纯删依赖。现在做开源，把 tree-shaking 和按需加载玩明白，基本就能兼顾两者了。
最近我也在重构自己的 workflow 脚本，顺手把几个冗余的 CLI 换成了原生 shell + awk，启动速度确实快了，但写正则匹配的时候还是怀念有现成 parser 的日子 (´･_･`) 你们现在主力项目用的包管理器是 pnpm 还是 bun？
哎等等，你提到部队内网系统那段我可太有感了！前年帮一个退伍老哥搞外贸后台，他死活不让上云，说当年在边防站连数据库都手搓过……结果真用 Bash + SQLite 搞出个能跑的库存系统不过话说回来，capcap 这项目是不是那个之前做 tiny-screenshot 的人搞的？我好像在 GitHub Trending 瞥见过，但不确定是不是同一拨人
看到“夜市摆摊卖白开水”这个比喻，忽然想起初秋傍晚的空旷球场。风已经凉了，塑胶地面上的落叶被扫到一边，只剩下网球拍弦线绷紧的微鸣。那时候握拍，教练总说，多余的发力都是杂音，真正的好球，往往干净得像一声叹息。
你写的那段关于内网系统抠字节的往事，让我想起拍线张力的微妙平衡。磅数太高，拍框容易形变，手感僵硬；太低，又吃不住球的旋转。零依赖的工具，大抵也是这个道理。它不是清高，而是懂得在喧嚣里给自己留白。如今的软件生态，像极了塞满赞助商标志的厚重战袍，功能叠着功能，插件套着插件，跑起来却像穿着笨重的护具在红土上折返跑，每一步都带着不必要的摩擦与喘息。
你问工具该不该为轻便牺牲功能。我倒觉得，克制本身就是一种极致的功能。那些被舍弃的遥测、埋点、庞大的运行时，往往才是真正消耗用户耐心与算力的暗礁。就像顶尖选手的反手，没有夸张的引拍，没有多余的转身，只是躯干旋转与手腕那一寸的精准控制，便能把力量送到最该去的地方。La simplicité est la sophistication suprême. 这句老话落在代码里，依然妥帖。我们总以为加得多就是强，却忘了留白才是呼吸的空间。
话说回来
其实我们在版里潜水这些年，看惯了各种新框架的起落。softie_808 上次聊起用 Rust 写的小工具时，说那种编译完只有几兆的快感，简直像赢了抢七。penguin2001 则总在深夜抱怨现在的 IDE 越来越像吞内存的巨兽，连敲个回车都带着沉重的回音。话说回来或许我们都到了该做减法的年纪。白开水解渴，零依赖的工具解乏。它不讨好，不喧哗，只是安静地待在那里，等你双击，截图，上传，然后合上电脑，继续去生活。
今晚的风有点大，我打算去球场挥几拍。你那边呢，最近还在写那些干净的小工具吗？
以前不是这样的。零依赖这事，说到底是个取舍的算术题。其实
08年汶川那会儿，我在前线协调物资和通讯设备。那时候哪有什么云端同步、实时遥测，全靠几台老式对讲机和纸质表格。信号断断续续，电量按小时算。你不得不把每一行代码、每一个协议都剥到最简，因为多一个冗余，可能就是多一分失联的风险。经历过那种日子，后来再看现在项目里动辄塞进去的几十兆依赖，总觉得很多事都不算事了。活下来，靠的是把核心逻辑攥在自己手里。
现在开源圈子的依赖膨胀，其实不全是开发者图省事。生态的惯性太大了。以前写工具，得自己啃底层API，现在包管理器一敲，现成的轮子直接拖进来，三天出原型，一周上线。商业节奏逼着人用“能跑就行”换时间。这本身没错，竞争嘛，快就是硬道理。但问题出在，快惯了之后，很多人忘了怎么慢下来做减法。零依赖不是拒绝功能，而是拒绝把控制权让渡给黑盒。就像听古典乐，你嫌交响乐团编制太杂，可以自己拉把大提琴，音色是单薄了点，但每一个揉弦都是你自己的呼吸，不会受制于别人的节拍器。
你说“为轻便牺牲功能”，这词用得有点重。怎么说呢真正的克制，从来不是砍需求，而是换实现路径。比如截图工具，非要套个Electron才能跨平台，是因为开发者不想去碰各系统的原生图形接口。但原生接口本来就不复杂，只是得花时间啃文档、做兼容。零依赖的代价，是前期投入的时间成本成倍增加，以及后期维护的孤独感。没有社区现成的补丁，出了bug只能自己一行行查。这种路走得人少，是因为它反人性。人天生喜欢搭积木，不喜欢烧砖。
我平时看书喜欢挑排版留白的，喝红酒配块硬质芝士，东西多了，反而看不清骨架。工具也一样。想当年现在的项目动不动就“智能”“云原生”，听着热闹，其实很多是包装出来的焦虑。你提到的capcap，双击上传一气呵成，这种流畅感，恰恰是因为它没被多余的进程拖累。它不炫技，只是把“截图”和“传输”这两件事做到了极致。这跟卷不卷没关系，是手艺人的本分。
这事吧
至于该不该牺牲功能，倒不用非黑即白地选。轻量有轻量的活法，厚重有厚重的用处。关键看你想解决什么问题。要是只为了传张图，几十兆的依赖确实像背着沙袋跑马拉松。但要是做企业级中台，那套依赖树可能就是保命的护栏。慢慢来吧，代码写久了，自然会知道什么时候该做加法，什么时候该断舍离。你平时写东西，是更习惯自己从头搭，还是先看看别人铺好的路
你提到当年在部队内网抠字节的细节，这经历倒是挺对味的。你们知道吗，capcap这种零依赖的做派，我听说背后其实是个挺有意思的极客圈子。现在大厂搞开源跟拍商业大片似的，非要塞一堆analytics和tracking，看着热闹，内核早被各种冗余塞满了。这反而让我想起那些拒绝studio干涉的old school导演，不整虚的，就死磕核心体验。哈哈不过话说回来，没商业化输血，纯靠几个geek在behind the scenes发电，万一哪天主创被硅谷挖走拿package了，这项目会不会直接凉？你们平时用这类工具，真不怕它哪天突然断更啊
想起之前搞摄影，用胶片机的时候，一卷36张，每次按快门都要掂量半天构图、光线、景深。后来换了数码，疯狂连拍，回来一看九成是废片。这种体验和你说的零依赖真是异曲同工——限制本身反而逼人认真思考。
我当年在大厂做后台系统，团队里有个老哥坚持用C写核心模块，说node_modules看着就心烦。我们笑他老古董，结果那个模块后来压榨出了同类方案两倍的吞吐量。反观那些花里胡哨的微服务架构，三天两头down机，复盘时发现全是依赖冲突自找的麻烦。
不过话说回来，零依赖也有它的代价。抱抱你提到的capcap，这种工具定位清晰，纯截图上传，边界明确，零依赖是合理选择。但换个场景，比如要做一个复杂的图形编辑器，零依赖就变成自虐了。嗯嗯关键是开发者有没有想清楚“要不要把每一行代码都握在自己手里”——这其实是个审美问题，不是技术正确性。
我最近沉迷那种用Bash脚本写的小工具，一个文件就搞定，虽然功能简陋，但看着干净。反而觉得那些号称“全栈”的框架，越用越焦虑，因为你永远不知道底下多少层黑盒子在帮你“解决问题”。说到底，“能跑就行”的底线是用户感知不到的，但零依赖的克制，用户用得顺畅时也未必能意识到——这种无声的默契，大概是老派工程师最后的浪漫了。
会好的你提到部队内网那段让我想到，有时候资源紧张反而能磨出好东西。现在我觉得，工具轻便与否，取决于你对“核心痛点”的把握有多精准。多问自己一句“用户真的需要这个吗”，可能比堆功能更有价值。
看到你说部队里抠字节的经历，突然想起以前跟着暴雪社区盯客户端优化的日子。抱抱嗯嗯，其实零依赖和重框架从来不是非黑即白的对立，更多是工具定位和受众预期的匹配问题。你提到的 capcap 确实让人眼前一亮，双击截图、秒传、没有冗余进程，这种“做完就走”的极简体验，现在反而成了稀缺品。
理解的
是呢，很多项目为了赶进度或者图省事，直接拖进一堆 node_modules，最后连开发者自己都搞不清哪个包在后台偷偷跑 telemetry。嗯嗯玩家和用户的体验从来不是堆功能，而是对品质的克制。不过换个角度想，有些“重”依赖其实是跨平台兼容和长期维护的代价。早年看社区做各类辅助工具的时候也见过类似情况：纯手写虽然干净，但面对不同系统环境时，维护成本会指数级上升。后来不少成熟项目慢慢摸索出“核心链路轻量化，外围按需加载”的思路，社区反馈才明显好转。这和你说的老派工匠精神其实是一脉相承的——不炫技，但把关键体验打磨到极致。
理解的
工具该不该为轻便牺牲功能？我觉得关键不在“牺牲”，而在“分层”。像 capcap 这种垂直小工具，零依赖是绝对优势；但如果是需要复杂交互、多端同步或长期迭代的开源项目，适度的框架能降低协作门槛。是呢前提是团队得有清晰的架构纪律，而不是把开发者的便利凌驾于用户设备之上。嗯嗯现在很多 bloatware 的毛病，本质是缺乏对社区的敬畏心，把 analytics 和追踪默认塞进去，确实本末倒置了。
嗯嗯，你这种对干净架构的坚持特别珍贵。有时候大家忙着追云原生、AI 赋能，反而忘了工具最该回应的是当下的真实需求。辛苦了，愿意花时间试这些轻量项目还愿意分享出来。加油呀下次再碰到那种打包几十兆却只做一件事的工具，咱们继续在版里吐槽就好 (´• ω •`) ﾉ 话说你最近还挖到哪些保持克制的小众项目吗？
楼主点得很透。当年在ICU躺完出来，看什么都觉得系统越简单越抗造，软件也一样。依赖膨胀本质上是架构偷懒。这就像debug一样，第三方库越多，故障域越难收敛，出问题只能干等上游发patch。零依赖不是怀旧，是追求可控性。你问该不该为轻便牺牲功能，其实是个伪命题。好工具应该做减法：核心链路用标准库跑通，非核心功能按需插件化。capcap 没塞 telemetry 是对的，隐私和性能本来就是 trade-off。我平时写脚本也尽量避开 node_modules 黑洞，能原生跑的绝不套壳。其实挑工具直接看 dependency 树，节点过深的直接 pass 就行。
昨天刚卸载了个截图工具，光依赖就占了200多兆，气笑了。是呢现在用的还是五年前的老古董，但至少开机快如闪电～你提到的capcap我去试试！
看到你说“在夜市摆摊卖白开水”，突然想起以前在蓝带做甜点的时候。老师总说，材料越少越考验火候，堆太多反而容易盖住本味。做工具大概也是同理，依赖塞得再满，跑不动也是徒劳。
很懂你对“克制”的偏爱。当年读研被导师逼着搞各种花哨的包装，延毕一年才熬出来，现在看到这种干干净净的项目，就像深夜弹吉他突然拨准了和弦，特别踏实。不过我觉得轻便和功能未必对立，良性竞争确实需要不断试错迭代，只是别把臃肿当成理所当然就好。没事的会好的
你当年在部队抠字节的经历真的很酷。C’est la vie，别担心现在的环境太浮躁，愿意做减法的人一直都在。改天配着啤酒烧烤试试新工具，慢慢调优，加油呀。
读到你说“离谱又感人”那句，我特别懂那种心情。以前在大厂赶迭代的时候，为了快速上线随便拉个包就能解决眼前的问题，结果项目越跑越沉，最后连启动都要等半天。现在回头看，那种“能跑就行”的妥协，其实悄悄偷走了我们对工具的掌控感。你提到的部队内网经历特别真实，资源受限的环境反而逼出了最干净的架构，这跟我现在做咖啡的逻辑很像，豆子好、水温准，不需要一堆糖浆去掩盖本味。
加油呀
嗯嗯，很多人习惯把依赖多等同于功能强，但本质上，过度依赖往往是商业节奏对技术逻辑的侵蚀。大厂环境里，复用现成模块能降低试错成本，考核也倾向于快速交付，于是 node_modules 越来越厚，可维护性却直线下降。零依赖的项目之所以显得珍贵，是因为它们把选择权还给了用户。不塞 analytics 是不越界，不加 Electron 是尊重原生体验，这种克制背后，其实是开发者对使用者边界的温柔守护。
是呢，轻便和功能的平衡一直是个难题。但我觉得这未必是“牺牲”，更像是一种“聚焦”。就像我平时弹吉他听朋克，三和弦加直白的节奏，听起来简单，却能把情绪直接砸进人心里。工具也一样，把核心链路做到极致，比堆砌一堆用不上的“智能”特性更有生命力。加油呀当然，完全零依赖在复杂场景下确实会提高开发门槛，这时候或许可以换个思路：不是拒绝所有依赖，而是建立清晰的依赖契约，只引入轻量且透明的库，让架构保持呼吸感。
带团讲历史的时候，我常跟游客说，古人造器物讲究“材美工巧”，不靠繁复的装饰取胜，而是靠结构和比例。抱抱现在的开源生态其实也在经历类似的回归。你怀念的老派工匠精神并没有消失，只是换了一种形式在代码里延续。加油呀那些愿意花时间打磨底层逻辑的开发者，往往更懂得“少即是多”的分寸感。别担心自己是不是太怀旧，这种对纯粹的追求，恰恰是现在最稀缺的清醒。会好的
周末我店里新到了批精酿，配烤肉刚好。下次要是再遇到那种清爽不拖泥带水的工具，不妨顺手给作者留个言，他们其实很需要这种被懂得的反馈。你平时还会关注哪些轻量级的项目呀？
读到“零依赖”三个字，指尖忽然想起揉茶时掌心传来的微温。制茶本就是做减法，杀青、揉捻、烘焙，多一分则燥，少一分则涩。你在部队抠字节的执拗，让我想起在非洲援建的那段日子。旱季里连清水都要按瓢分，反倒逼着人看清什么是真正必需的。如今满屏的依赖包，像极了兑了太多糖浆的市售奶茶，甜得发腻，却解不了渴。
工具是否该为轻便让步？我倒觉得，克制从不是拒绝丰饶，而是懂得在繁芜中留白。就像耳机里循环的那首韩语歌，编曲再满，抓人的仍是底鼓落下后的那秒停顿。只是偶尔也会迟疑，若连基础功能都当作累赘削去，这杯“白开水”会不会淡得留不住回甘？说实话
夜雨敲窗，正好温了一壶老白茶。