Posts

过去几个月，Coding Agent 基本成了我每天都会用的工具，我自己已经很少直接写代码了。 去年差不多这个时候，我还在问：Claude Code 真的能在一个维护了 6 年的 repo 里完成实际的开发工作吗？现在看来，这个问题的答案已经很清楚了。 但很长一段时间内，让我头疼的不是 Coding Agent 能不能写出合格的代码，而是我怎么和它一起工作。 之前有一段时间，我同时开了太多 thread。每个 agent 都在疯狂输出，看起来所有的事情都在推进，但最后交付的结果没有一个真正令我满意。也是从那时候开始，我尝试做 Human Context Engineering ，限制同时进行的事情，把自己的注意力留给设计和判断。 这样工作了两个月之后，这个适合我的工作流慢慢清晰了起来。 它其实很简单：Shift Left。 软件工程从来不只是写代码。粗略一点，可以把它分成两部分：左边是理解问题，右边是代码实现。 刚工作那几年，我的大部分时间都花在右边。随着经验越来越丰富，花在左边的时间也越来越多。在 Coding Agent 出现之前，两边大概是 50/50。 我以前会有意识地给写代码留出至少一半时间。因为不管前面想得多清楚，只要代码还没跑起来，接下来会遇到什么其实是个未知数。 可能是兼容性问题导致服务挂了，也可能是刚升级的包改了接口。很多问题必须真的跑一次才会出现。出现以后，还要看 changelog、搜 Stack Overflow，再一个个试可能的解法。 这些事情很花时间。所以我的习惯一直是：不要让计划占据大部分的时间，至少留一半时间给实现。 这个方法以前一直有效，我也很相信它。 Coding Agent 出现之后，这套方法开始不太适用了。 我不可能比 Pi 或 Claude Code 写得更快，也不可能比它更快读完一堆 changelog。到了睡觉时间，我要去睡觉，它还可以继续跑。 但快不代表结果一定可靠。对我来说，最难受的情况并不是 agent 跑得慢，而是它跑了很久之后，交回来一个我不敢用的结果。时间花了，token 也花了，最后还得重新来一遍。 Agent 有点像一辆开到 300 km/h 的赛车。方向对了，很快就能到；方向错了一点，也会很快撞上去。 所以我开始改变分工：把大部分时间放到左边，想清楚之后再交给 agent。 现在我会反复校订 spec，直到它能清楚回答这几个问题： ...

最近我意识到一件让我有点焦虑的事情：AI 正在蚕食掉我的注意力。 它不是短视频、社交媒体那种很明显的分心，而是一种更隐蔽的分心，因为它看起来很像生产力。Terminal 里有任务在跑，agent 在改代码，文件不断被创建，commit 一个接一个出现。仿佛我一直在创造，但一天下来，好像没有什么东西真正完成。 我会同时开好几个 agent coding session：一个做 feature，一个修 bug，一个探索等待结果时突然冒出来的新想法。表面上看，我做了很多事。但等这些 agent 带着执行结果回来时，我甚至没有精力认真验证其中任何一个结果。真正限制我的，不再是编码能力，而是观察、判断和继续推进的能力。 有了 AI 之后，我很容易产生一种“我变强了”的错觉。某种意义上，这也没错。我实际的产出确实变多了。AI 可以修编译错误，生成测试，做重构，也可以更快地搭出界面。有了 AI 加持，我能做比之前多很多的事情。问题是，执行能力变强之后，真正卡住我的地方也变了。我的瓶颈不再是把需求变成代码的速度，而是自己的 context window：它有多长，以及里面装的 context 质量如何。 是的，AI 有 context window，人其实也有。当脑子里同时挂着太多未完成的事情时，我就会开始失去判断力。 更有意思的是，我不是因为时间不够用而导致的注意力过载，而恰恰是因为 AI 接管了很多琐事之后，我每天的工作中间会多出来一些空档。五分钟，十分钟。我的注意力也被摊开到了那些过去根本不会出现的缝隙里。如果这些时间没有被提前安排好，我的大脑就会不由自主地去做最容易的事情：开始另一个想法。 开一个头很容易，真正把它收尾就没那么容易了。而 AI 让“开始”变得几乎没有成本，这其实很危险。 AI 可以生成不错的结果，但大多数时候，它生成的是 good enough 的结果。 如果想让结果真的变得理想，我还是需要读 diff、理解它生成的测试的行为、发现哪里不对劲、决定什么要保留、什么要删掉、下一步往哪里走。这一部分目前还很难完全丢给 agent,至少对于我在意的工作来说，我仍然要负责 taste、判断和方向。 但当我同时挂着十件毫不相关的事情时，我没法把这个角色做好。我会失去耐心，会扫一眼就过，而不是认真审阅；会太快 approve 一些东西；会忘记自己一开始为什么要做这件事。我的后续指令也会变得模糊，而模糊的指令通常只会得到模糊的结果。 最后就变成：一天开了十个头，但没有一件真正收尾。看起来很忙，实际上却没有什么东西被真正完成。这给我带来了很多的焦虑和内耗。 所以我开始把自己的注意力也当成一个工程系统来管理。 我们经常讨论怎么给 AI 做 context engineering：prompt 里应该放什么，应该带哪些文件，如何保存记忆，如何避免 context pollution。但我现在觉得，人也需要 context engineering。 我的规则很简单：一天里，我最多只开三个 workstream。不是三个小 task，而是三个真正需要判断力的事情。一个 feature，一个 bug，一个设计上的调整，或者是构思一篇文章。只要这件事需要我认真观察和做决定，我就会把它定义成一个 workstream。 在开始一个 workstream 之前，我会先花 20 到 30 分钟思考： ...

最近看到不少关于 harness engineering 的文章，中文圈和英文圈都有。 但大多数只是在讲概念，细节很少。而且说实话，有些系统描述得太复杂了，很难相信它们真的能稳定跑起来。 于是周末我自己动手试了试。 说来有点好笑，我做过很多个人项目，但大部分撑不过 10 次迭代。所谓"撑不住"，就是进入了一种死循环：加一个功能引入了 bug，修这个 bug 又带来新的 bug。 而 harness engineering 要解决的，正是这种螺旋式崩塌。 很多人把它讲得很复杂。但我自己尝试下来，核心思路其实挺朴素的。原文 中其实有两点，我觉得非常关键。 第一条：让 worktree 能直接启动。 这是让多个 agent 并行工作的前提。 前端包管理器用 bun（或者 pnpm），不要把时间浪费在装依赖上。数据 pipeline 的环境依赖用 uv 管理。每一个 worktree 都能快速启动。 第二条：定好标准。 把每个需求当成一张完整的 ticket 来处理。Lint、单元测试、构建通过——这些是基础。但如果是有 UI 的应用，UI 测试是比较关键的一环。 这里我用的是 agent browser 和 Playwright CLI 。它们和传统 e2e 测试不同，不会因为 selector 变了就挂掉。你只需要配合它们跑一两轮，描述你的应用长什么样，然后把结果写进一个 markdown 文件。 之后你只需要说：“当我点击 X Button 时，Y 应该出现。” 验证规则用纯自然语言描述就行了。 定下这两条规则花了我最多的时间。剩下的——技术栈和基础设施——我自己来决定。代码交给 agent 写，架构还是得自己拿主意。 然后，构建过程就开始自己运转起来了。 我创建了一个叫 decision-plan 的 skill。 ...

最近，我突然多了很多时间。 我脑子里充满了各种想法，但一切却又显得模糊不清——我要不要看看新机会，全力准备面试？要不要做一些之前就计划的个人项目？还是尝试一些新的方向？选择变多之后，决定反而更难做了。 于是我做了一个很典型的选择：进入“全速冲刺模式”。 我试图在一周内快速补齐前端基础和系统设计，给自己设定了很激进的目标，每天学习到很晚，逼着自己持续输出。刚开始的几天确实有效，但很快我就开始感到疲惫。 接下来的一周，我几乎什么都不想做。两周过去了，我离自己原本的目标依然很远。 后来我在《Effortless》这本书中读到一个故事。 1911 年，有两支队伍争夺成为第一个到达南极点的人：Robert Falcon Scott 和 Roald Amundsen。 Scott 的策略是：在天气好的时候尽可能快地前进，在天气恶劣的时候减速甚至停下来；而 Amundsen 则采取了完全不同的方式——无论天气如何，每一天都保持稳定的节奏前进。 最终，Amundsen 率先到达南极点。 这个故事对我的触动很大。 问题的关键并不在于你能冲得多快，而在于你能以同样的节奏走多远。 于是我开始调整自己的方式。 我不再强迫自己每天完成 5 道系统设计题，而是把目标降低到每天只做 1 道，并且坚持每天都做。 看起来进度变慢了，但由于不再过度消耗，我反而有了更多稳定的精力去持续推进。同时，我也开始有余力去探索一些有趣的方向，比如 agent 或工程化相关的内容，而这些探索反过来也对我的一些面试产生了帮助。 我逐渐意识到一个很重要的点： 不要把自己逼到第二天无法恢复的程度。 一旦恢复能力被破坏，整个节奏就会开始崩塌：计划延误、压力上升、你会试图更加用力去追赶，结果反而更容易再次透支自己，进入一个不断循环的消耗状态。 另外一个帮助我维持节奏的关键，是在每天开始之前就明确当天要做的事情。 哪怕只花 10 分钟，在睡前或早上简单规划一下。 人的注意力和精力是有限的，每一个微小的犹豫、情绪波动或者不确定性，都会占用大脑的资源。当脑海中充满模糊和未决事项时，就很难再腾出空间去处理复杂的问题，随之而来的往往是焦虑，而焦虑又会进一步消耗精力。 所以现在我的做法是： 提前把事情想清楚并记录下来，让执行过程尽可能简单直接； 控制每天的任务规模，让自己始终处在一个可以恢复的节奏中； 然后像一个执行系统一样，按计划推进。 归根结底，真正重要的不是一时的爆发，而是你能否持续前进。 比起速度，更重要的是节奏。 也许你不需要更快，不需要更努力。 你需要的是——守住自己的节奏。

今天，我想聊聊 专注。 在现代信息社会，专注其实是一种非常难得的品质。 抖音上刷不完的短视频，公众号不停推送的文章，小红书看不完的分享。信息流无穷无尽，总有新的内容在争夺你的注意力。 很多时候，我们明明在进行重要工作，却还是忍不住分心，拿起手机刷刷朋友圈。 互联网上很多 UP 主已经从脑科学和多巴胺的角度解释过这个现象。《认知觉醒》一书中提到，专注其实是一件反人类天性的事情。因为专注意味着你的大脑在不停地思考，而思考是一件极为耗能的行为。 人作为一种生物，本能上会抵抗高耗能行为。 相反，娱乐和放空是一种低耗能行为。（别告诉我你刷抖音的时候还在思考。） 所以我们天然会倾向于那些更轻松、更即时带来快乐的事情。这并不是什么羞耻的事情，这是人的本能。 而最近很流行的 Vibe coding，某种程度上来说，其实也是一种分心。 一段时间里，我沉迷于把日常使用的工具都用 AI 重新 vibe coding 一遍。 看着一个个文件被创建，应用慢慢跑起来，界面也像模像样地出现，那种感觉其实挺爽的。仿佛在极短的时间里就做出了很多东西。 但过了一段时间之后，我开始陷入一种 AI 疲劳。 五个 project 同时运行，不停在不同项目之间切换上下文，我的大脑长期处于一种过载状态。 再回头看这些 vibe coding 的项目，我突然发现： 我其实已经看不太懂它们了。 更糟糕的是，我也不知道接下来该做什么。 理论上，我创建了五个新的、可以跑起来的应用。 但回顾起来，我几乎没有真正学到什么东西。 我没有进行太多系统性的思考。大多数时候只是机械地输入一些简单得不能再简单的需求，然后等待 AI 输出结果。 不可否认，Vibe coding 确实有它的价值。 它可以快速验证想法，快速创建小工具。 对于非技术背景的人来说，只需要提出需求，就可以开发出一些应用来自动化重复工作。 在某种意义上，AI 确实降低了软件开发的门槛。 但问题也恰恰在这里。 因为 Vibe coding 让“动手实践”这件事情变得成本极低，它第一次打破了一个原本非常重要的循环： 学习知识 → 产生思考 → 动手实践 在传统的学习路径中，实践是建立在理解和思考之上的。 而在 vibe coding 的模式下，这个过程往往被压缩成： 想法 → AI生成 中间最重要的一步 —— 思考 —— 很容易被省略。 而思考过程的缺失，其实是致命的。 在知识学习的过程中，思考往往是杠杆最高的一环。 如果没有这一环，你以为自己在不断“实践”，但实际上，大部分时间可能只是低效地生成代码而已。 ...

工作 挣扎 2021 年，是我在西安腾讯的第二年，去年抱着满腔的热情加入公司，认识了很多不错的人，年底也收获了还不错的绩效，但是整个人却就是开心不起来。呆小瓜，包括我身边的很多朋友，都觉得，我没有之前开心了。现在想想那段时间，一方面是自己的状态确实太紧绷了，每天睡觉前都在担心 on-call，即使下班后也是盯着企业微信，担心有人找。另一方面又感觉自己没有任何成长，在不停的做重复的事情，没有时间思考，开始不断怀疑否定自己。这样的状态持续了大概三个月左右，在确定了未来业务方向自己实在不感兴趣，和呆小瓜吐露心声并获得她的支持之后，我便开始了新的工作规划。 机遇 在经历了几轮面试之后，我成功拿到了 3 个 offer。很幸运，自己之前在 toughtworks 的经验，还不错的英语底子以及爱折腾的经历给自己加了不少的分，让我保持了尚可的竞争力。综合考虑下我选择来到上海，加入 Afterpay(现在应该叫 Block 了)。 成长 Afterpay 的工作节奏和我之前在 thoughtworks 的工作节奏比较一致，这也给了我更多的时间去思考。前端的工作内容其实大同小异，并没有什么新的花样。但是和两年前相比，由于有了不同的经历，自己的视角也有所不同。过去的我更多的是从一个前端的角度去出发，把产品需求转变成技术代码。但现在自己会思考更多，不仅是 technical 上(从前到后端到端，如何规避技术风险，如何选择合适的技术高效支持业务，如何针对不同的业务场景，选择合适的模型)，也会开始从产品本身，从商业模型上思考如何打造更好的产品。我想我应该还是更适合做产品吧，希望 2022 年，能够逐步构建自己真正满意的产品，不管是从业务上孵化，还是自己的 side project。 生活 Move 伴随工作地点的变换，我和呆小瓜离开了我们居住了快 3 年的温馨的西安小窝，搬到了上海的出租屋。强调是出租屋，是因为在我们有限的预算下，能够租到的房子实在屈指可数，目前这套已经是矮子里面找将军，相对不错的一套了，不过相比之前自己的房子，仍有诸多不足之处。我们也不止一次的吐槽过如同纸糊的窗户，超小的电视，以及形同虚设的隔音。虽然有很多槽点，但是生活也有了一些惊喜，比如无意间的发现的步行就可到达的菜市场，意外好吃的干米粉，热情的卤菜阿姨和卖干货的大姐，以及我们给我们提供无尽造梗素材的周边的一切。虽然和西安相比，还是有点不太习惯这边的生活，但是一切都在变好。即使是出租屋，也在一天天变得温馨。 颠倒 呆小瓜因为要陪我来上海，也换了新的工作，当她给前公司提离职时，离职原因美其名曰“随军”(源自父母爱情的一个梗)。到了上海后，呆小瓜的工作比我强度要高，我们的位置就像是 2021 的彼此倒了个个，我开始成为后勤主管，而呆小瓜开始做女强人。这样的生活和我们最初的设想其实有所偏差，毕竟我们现在连 7 点吃晚饭都做不到，更别说之前设想好的培养兴趣爱好了。我也有些自责让她为了陪我来上海就变得这么辛苦。但是呆小瓜就是这么一个小仙女，一眼就能看出我心里在想什么，明明自己每天工作的很累了但是还是装作没事人一样听见我的烂梗就哈哈大笑。新的一年，希望呆小瓜能够轻松一点，也希望我们能实现每天 7 点吃晚饭的目标。 厨艺 经过去年年夜饭的洗礼，自己今年的厨艺又精进了很多，下面是几个自己今年最满意的菜。 肉炒一切(蒜薹，香干，洋葱) 芋儿鸡(YYDS) 萝卜(扁豆)炖牛肉(没有老妈做的味道那么浓，但是意外的合我和呆小瓜的口味) 锅巴饭(偷师石泉)和砂锅(自成一派) 清蒸鱼(主要是鱼的功劳) 希望新的一年能解锁新的菜单，能够开始烹饪一些不一样的新食材。 总结 每年回顾，都会有很多遗憾，这里列几个个人觉得做得非常不好的地方 没有太多的时间陪伴父母(去年过年没回家，今年打算错峰过年)。 又是几乎没有读书的一年，知识来源过于零散化，虽然开始使用双链笔记进行整理记录，但是没有形成体系。 成长上有点停滞不前，对于新的东西学的很快，但是还是没有发现自己的核心竞争力。 博客更新几乎停滞。本来想着工作节奏慢一点就能多写点东西但是零散时间大多数被 b 站和游戏占据。 没有发展任何新的技能和爱好。 如果我能够把上面这些事情全部都做完美，不留遗憾，那我新的一年应该是个超人了。但是我并不是什么超人，遗憾也总会有，暂且实际一点，希望明年能少一点遗憾，加油！

什么场景下需要跨tab通信？ 有一些日常中很常见的场景，如果支持跨tab通信，可能能给用户更好的体验。 博客Dark Mode切换 想象你在浏览 Dan Abramov的博客 ，你同时打开了好几个tab学习一系列知识。夜晚来临，你将一个页面切换成了Dark Mode。当你阅读完这一篇去阅读下一篇时，页面却不是以Dark Mode呈现的。你不得不按下F5刷新页面来寻求一致的阅读体验。 需要频繁登录的CMS系统 想象你在网店管理系统中管理你网店中的商品，你打开了好几个tab，分别管理商品类型，商品详情以及商品库存。你正在管理你的商品详情，突然你的登录session过期，你点击重新登录。但是当你切换到商品库存页面时，你发现你依旧无法操作，需要再次登录。你不得已点击了登录按钮，和你辛苦编辑了10分钟但没有保存的商品库存说了拜拜。 以上场景其实无伤大雅，你的系统依旧运转，核心功能依旧正常。但是借助跨tab通信，你能给用户提供更好更顺滑的体验。 Cookie & IndexedDB 要实现数据的一致，很容易想到的就是统一的数据存储。在有后端加入的时候，后端其实就是前端的统一数据存储。在纯前端的环境下，比较常见的数据存储包括 cookie localStorage sessionStorage IndexedDB sessionStorage 由于只存活于单个tab session中，所以不能用于跨tab通信。localStorage 有其他的应用方式，下面会深入分析。所以在这个章节我们主要关注cookie和IndexedDB。 实现思路 实现思路其实非常简单，就是通过轮询数据源，来确保每个tab的数据都是最新的。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 // Cookie Way // Producer Tab, 当然你也可以用js-cookie这种库更高效的操作cookie document.cookie = "blabla" // Consumer Tab setInterval(() => { const cookie = document.cookie; //Use Cookie to do something doSomething(cookie) }, 1000) // IndexedDB way // Producer Tab const transaction = db.transaction(["customers"], "readwrite"); const objectStore = transaction.objectStore("customers"); customerData.forEach(function(customer) { const request = objectStore.add(customer); request.onsuccess = function(event) { // do some callback }; }); // Consumer Tab setInterval(() => { const transaction = db.transaction(["customers"]); const objectStore = transaction.objectStore("customers"); const request = objectStore.get("444-44-4444"); request.onsuccess = function(event) { doSomething(request.result.name); }; }, 1000) 需要注意的是，cookie的读写是同步的，在cookie比较大的时候可能会阻塞主线程造成页面卡顿。而IndexedDB的API都是异步的，所以不会有cookie同步读写的性能问题。 ...

什么是Github Actions Github Actions 是 Github 推出的一项服务，旨在以自定义工作流的方式来简化团队开发协作中的各种需求。比如： 基于 Code Commit 的代码构建/测试/打包，也就是常说的持续集成。 应用的自动发布和部署，和上一步连起来就是所谓的持续部署。 自动管理 PR（如自动 assign viewer） 自动管理 issue（如自动给 issue 分类，自动关闭长期不更新的 issue ） Github Actions的优点 1. 灵活性 对比主要竞品 Jenkin/GoCD 以及 Circle CI/ Travis CI， 相较于 Jenkins/GoCD 只能够自建服务，CirCle CI(2.0以前) / Travis CI 只能依靠官方提供的服务，Github Actions 可以使用 Github 官方的 Runner，同时 Github Actions 也支持使用用户自建的（比如搭载某内网环境的instance）Runner。Github Actions 还自带 Linux/macOS/Windows 三种类型的 Runner，能够满足不同用户群体在不同场景的需要。 2. 复用性 对于开发者而言，编写重复的代码永远都是一种灾难。而在 Github Actions 的准则中，每一条 Action 都是一个最小的可复用单元，只需要一次编写，便可以在之后随时随地的使用。更棒的是，Action 可以通过组合的方式来使用，完成更为复杂的功能。 3. 可维护性 每一条 Action 其实就是一个 JavaScript module/Docker container，由于Action 本身就是代码，所以 Action 本身是可以很好的被版本管理的。同时由于支持使用 JavaScript 编写 Action，只要你想，你可以使用大量的测试来保证你的 Action 的质量。 ...

为什么 z-index 不工作了？ 在某些场景下，我们经常会发现z-index不知为何就不工作了，比如下面的场景。（demo：stackblitz demo ) 1 2 3 <div class="block-a">block-a z-index 1</div> <div class="block-b">block-b z-index 2</div> <div class="block-c">block-c z-index 3</div> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 .block-a { background: #ffb3a7; z-index: 1; position: relative; top: 60px; opacity: .8; width: 500px; height: 90px } .block-b { background: #fff143; z-index: 2; opacity: .8; height: 100px; width: 320px; position: fixed; } .block-c { background:#bddd22; opacity: .8; z-index: 3; width: 200px; padding-top: 300px; } div { color: #50616d; font-size: 24px; text-align: center; padding-top: 40px; border: #50616d 1px dashed; } block-a的 z-index 是 1， block-b 的 z-index 是 2， block-c 的 z-index 是3。 按照之前的理解，覆盖关系应该是block-c覆盖block-b覆盖block-a。但是实际结果却如下图。 ...

基础类型 Undefined Null Boolean String Number Symbol Object boolean这个类型比较简单，不单独作解释。Symbol这个类型太复杂，后面单独总结。 Undefined 和 Null undefined并不是一个关键字。我们日常访问的undefined其实是访问的global级别的undefined变量，undefined变量的值是基础类型undefined。但是在现代浏览器中，undefined都不能被覆写。 undefined代表一个变量初始化了但是没有赋值，任何变量初始化前值都是undefined。 null是JavaScript的关键字，表示的是一个空值。 所有变量定义都不要赋undefined值，这样会让代码难以理解（到底是代码没有赋值还是？） String string的最大长度是2^53-1，但是长度并不是指代字符数，而是字符串的UTF16编码的和，比如需要计算一个emoji的长度，你会发现是2。 字符串方法比如length和charAt都是基于字符串编码和的。 字符串一旦构造便不可更改，属于值类型。 Number Js中除开规定有理数，还规定了NaN，Infinity，-Infinity Js中有+0和-0，在加减法中没有问题，在乘除法中，如果是 x * -0 会得到 -0，x/-0 会得到 -Infinity。 Js中的Number类型范围是-2^53-2^53，如果不使用BigInt，只能表示这个范围之内的整数 非整数类型的Number无法使用 == 或者===来进行比较，0.2 + 0.1 == = 0.3 会返回false，如果想要得到正确的匹配结果，请使用 Math.abs(0.1 + 0.2 -0.3) <= Number.EPSILON Object Js中对象是属性的集合。属性分为数据属性和访问器属性，以key-value结构进行存储，key可以是字符串或者是个Symbol类型。 Js中的类和Java中的类有一些不同，Java中的类代表的是真正的类型，但是Js中的类只是运行时对象的一个私有属性。 Number/String/Boolean和Symbol这四个基本类型都自带对应的构造器，如果使用 new 操作符，会返回一个对象类型而不是基本类型。 Js中的基本类型和对象的边界很模糊，可以直接在基础类型上调用方法，比如"abc".charAt(0)，也可以通过给原型添加方法给基础类型增加方法。 为什么基础类型可以调用对象方法？本质上是 . 运算符提供了装箱操作 ，这个运算符会根据基础类型构造一个临时对象。 类型转换 值转换表如下 StringToNumber String到Number的类型转换支持十进制/二进制/八进制和十六进制 30 0b111 0o13 0xFF 同时还支持科学计数法 ...