最近 quickjs-ng 的一个 PR 修复了一个属性赋值相关的 bug。排查过程中涉及到 ES 规范里 [[Set]] 的一条关键分支——“修改已有属性”和”创建新属性”走的是两条不同的路径。本文借这个 PR 的由头，聊聊规范里 extensible 检查到底发生在什么时候。

一个常见的失败场景

先看一段简单的代码：

"use strict";

var obj = {};
Object.preventExtensions(obj);

obj.x = 1;  // TypeError

对象被 preventExtensions 之后就不能再添加新属性了。规范是如何定义这个行为的呢？我们顺着 ES 规范的内部流程走一遍，就知道“不可扩展”这个检查到底发生在哪一步了。

规范里的执行流程

当我们写 obj.x = 1 时，规范里会依次进入这些”过程”（你可以把它们理解为引擎内部的函数调用链）：

PutValue(lref, 1)
  ↓
baseObj.[[Set]]("x", 1, baseObj)
  ↓
OrdinarySet(baseObj, "x", 1, baseObj)
  ↓
  // baseObj 上没有 "x"（ownDesc = undefined）
  ↓
OrdinarySetWithOwnDescriptor(baseObj, "x", 1, baseObj, undefined)
  ↓
  // ownDesc is undefined，查原型链
  ↓
Object.prototype.[[Set]]("x", 1, baseObj)
  ↓
OrdinarySet(Object.prototype, "x", 1, baseObj)
  ↓
OrdinarySetWithOwnDescriptor(Object.prototype, "x", 1, baseObj, undefined)
  ↓
  // Object.prototype 上也没有 "x"（ownDesc = undefined）
  // 原型链到头（parent is null）
  // ownDesc 被设为默认值 { [[Value]]: undefined, [[Writable]]: true, ... }
  ↓
  // IsDataDescriptor(ownDesc) is true
  // ownDesc.[[Writable]] is true
  // Receiver（baseObj）是 Object
  ↓
existingDescriptor = Receiver.[[GetOwnProperty]]("x")  // undefined
  ↓
  // Receiver 上无此属性 → 走"创建新属性"分支
  ↓
CreateDataProperty(baseObj, "x", 1)
  ↓
baseObj.[[DefineOwnProperty]]("x", { [[Value]]: 1 })
  ↓
OrdinaryDefineOwnProperty(baseObj, "x", desc)
  ↓
  // 先查属性是否存在 → current = undefined
  // 再查是否 extensible → false
  ↓
ValidateAndApplyPropertyDescriptor(baseObj, "x", false, desc, undefined)
  ↓
  // current is undefined，extensible is false
  // 规范：如果 !extensible 且 current 为 undefined，return false
  ↓
return false
  ↓
一路返回到 PutValue
  ↓
如果赋值语句处于严格模式 → throw TypeError

关键一步在 ValidateAndApplyPropertyDescriptor。这个抽象操作在创建新属性时会检查对象是否 extensible：如果不是，且属性还不存在，就直接返回 false。这个 false 一路传回 PutValue，最终根据是否严格模式决定是否抛错。

简单说：给不可扩展的对象添加新属性，规范在 ValidateAndApplyPropertyDescriptor 这一步拦住了。

那”修改已有属性”呢？

现在来看 PR 相关的场景。它要表达的核心问题是：如果我不是创建新属性，而是修改一个已经存在的属性，还会检查 extensible 吗？

我们把 PR 里的测试改写成一个更常见的版本：

var parent = { x: 1 };
var child = Object.create(parent);
child.x = 0;                      // child 上已有自己的属性 x
Object.preventExtensions(child);  // 让 child 不可扩展

child.x = 2;                      // 修改已有的 x，能成功吗？
console.log(child.x);             // ?

结果是：能成功，输出 2。

奇怪，child 明明不可扩展，为什么赋值还能成功？我们再走一遍规范流程，看看这次走的是哪条分支。

修改已有属性的规范流程

child.x = 2 进入规范后，同样走到 OrdinarySetWithOwnDescriptor。但这一次和前面的关键区别是——receiver（也就是 child）上已经有属性 x 了。

PutValue(lref, 2)
  ↓
child.[[Set]]("x", 2, child)
  ↓
OrdinarySet(child, "x", 2, child)
  ↓
OrdinarySetWithOwnDescriptor(child, "x", 2, child, ownDesc)
  ↓
  // IsDataDescriptor(ownDesc) is true
  // ownDesc.[[Writable]] is true
  // Receiver is Object
  ↓
existingDescriptor = Receiver.[[GetOwnProperty]]("x")
  ↓
  // existingDescriptor is NOT undefined！child 上已有 x
  ↓
  // existingDescriptor.[[Writable]] is true
  ↓
valueDesc = PropertyDescriptor { [[Value]]: 2 }
  ↓
Receiver.[[DefineOwnProperty]]("x", valueDesc)
  ↓
OrdinaryDefineOwnProperty(child, "x", valueDesc)
  ↓
ValidateAndApplyPropertyDescriptor(child, "x", false, valueDesc, current)
  ↓
  // current 不是 undefined（属性已存在），跳过 extensible 检查
  // 只检查 writable → true，允许修改
  // 更新 [[Value]] 为 2
  ↓
return true
  ↓
一路返回到 PutValue
  ↓
succeeded is true，赋值成功

注意这里 ValidateAndApplyPropertyDescriptor 的第 3 个参数 extensible 仍然是 false（因为 preventExtensions），但规范在这个分支的伪代码里写的是：

If current is undefined, then … if extensible is false, return false.

也就是说，只有当属性不存在时，才看 extensible。属性已经存在的话，extensible 直接被忽略，只检查 writable。

所以 child 虽然不可扩展，但因为 x 本来就存在，而且可写，规范允许直接修改它的值。返回 true，赋值成功。

关键的顺序问题：为什么 quickjs 会出错

我们稍微认真看一遍 ValidateAndApplyPropertyDescriptor

ValidateAndApplyPropertyDescriptor 的 current 参数是由它的调用方——OrdinaryDefineOwnProperty——通过 O.[[GetOwnProperty]](P) 查询后传入的：

OrdinaryDefineOwnProperty(O, P, Desc):
  1. Let current be ? O.[[GetOwnProperty]](P).
  2. Let extensible be ? IsExtensible(O).
  3. Return ValidateAndApplyPropertyDescriptor(O, P, extensible, Desc, current).

而 ValidateAndApplyPropertyDescriptor 收到 current 后，关键步骤：

1. Assert: extensible is true or false.
2. If current is undefined, then
   a. If extensible is false, return false.
   b. ...
   c. ...
   d. Else,
      i. Create an own data property named propertyKey ...
   e. Return true.
3. Assert: current is a fully populated Property Descriptor.
4. ...
5. ...
6. Return true.

注意步骤 1 和 2 的顺序：

1. 步骤 1（OrdinaryDefineOwnProperty 中）：先查询属性是否存在，得到 current
2. 步骤 2（ValidateAndApplyPropertyDescriptor 中）：只有在 current is undefined（属性不存在）时，才去检查 extensible is false
3. 步骤 3：如果属性存在，直接断言它是个完整的属性描述符，跳过 extensible 检查

这个顺序非常关键：先判断”有没有”，再决定”查不查 extensible”。

而 quickjs 在这个 PR 之前的实现，顺序正好搞反了。它在入口处就先检查了 extensible，发现对象不可扩展就直接拦截，完全没去判断属性是否已经存在。于是遇到下面这种情况：

var proto = { x: 1 };
var receiver = { x: 0 };
Object.preventExtensions(receiver);

receiver.x = 2;  // 规范：应该成功（已有属性可写）

quickjs 错误地先把 “receiver 不可扩展” 当成了拒绝理由，抛出了 TypeError（或在 Reflect.set 场景下返回 false）。规范的正确行为是：虽然 receiver 不可扩展，但 x 本来就存在且可写，赋值应当成功。

这个 PR 本质上就是把检查的先后顺序调回到规范定义的样子。

小结

ES 规范对每个操作都定义了精确的流程。extensible 限制的只是新增属性，不是修改已有属性。更准确地说：规范在 ValidateAndApplyPropertyDescriptor 中先判断属性是否存在，只在不存在的情况下才检查 extensible。把这个顺序搞反了，引擎就会错误地拦截合法的赋值操作。

最近有在 VSCode 里面用 Claude Code 插件。相比终端，GUI 交互是会更方便直观一些。这个插件支持在 VSCode 的 settings.json 里配置特定的字段，然后根据这些字段接入第三方模型。

但问题来了，每次都要在 VSCode 里直接编辑 settings.json 来切换 provider，太繁琐了。于是突发奇想：是不是可以写一个插件来自动修改 settings.json？于是花了一点时间 vibe 了一个插件。

个人觉得这个插件还是有一点点亮点的。比如它在首次运行的时候，如果你之前在 VSCode 的 settings.json 里配置过模型接入相关字段，它能解析出来并自动生成一个默认配置。此外，这个插件还支持从 bash 脚本片解析出配置。

初步搞完这个插件之后，把它分享到了 V2EX 上。收到的评论大概四五条，普遍认为这个插件的价值不高——这点确实没法否认。然后发现，大家使用 Claude Code 接入第三方模型的方式和我都不太一样。也有人提到 CC-Switch 这类已有工具，言下之意是这个 VSCode 插件其实意义不大。

于是在 v2ex 的帖子下简单解释了一下我的这个插件和 CC-Switch 的差异。比如说，我的插件不会有系统级别的影响，只在 VSCode 里面生效，从某种程度上来说会比较”干净”一些。如果你同时在终端和 VSCode 里使用 Claude Code，两者可以使用不同的 provider，因为它们的配置方式是独立的——这也算是一个小小的优点，虽然可能只是我个人比较小众的需求。

不过，V2EX 上这些热心网友的反馈也给了我一些反思的空间。确实，市面上已经存在一些 VSCode 插件或工具能够起到切换 Claude Code provider 的功能，虽然实现方式和我的不太一样，但对大部分人来说，这确实不是大家所在意的痛点。

现在在想，是不是可以继续做一个专门管理 settings.json 的插件，切换 Claude Code 可以只是这个插件的某个具体的使用场景 （有一个麻烦的点是，插件能够在 settings.json 修改的字段是需要提前申明）。这样的一个插件可能更有需求空间。

以上大概就是我这两天的一些心路历程，也是对 AI 辅助编程的一次探索，以及对于”如何发现需求、确定需求”的一点认识。

最后感谢 v2ex 的热心网友，促成了后续的一些思考。

PS: 以上内容为语音转录后， 人工 + deepseek-v4-pro 整理所得

相关讨论：https://www.v2ex.com/t/1210275

插件仓库：https://github.com/jiang1997/claude-code-profile-manager

The 4-step loop

# 1. Create the file. Name = date + URL slug.
$EDITOR _posts/2026-05-04-thoughts-on-rust.markdown

# 2. Top of the file — YAML "frontmatter" between two --- lines:
---
layout: post
title:  "Thoughts on Rust"
date:   2026-05-04 14:30:00 +0800
categories: programming
tags: [rust, language-design]
---

The post body in **Markdown** starts here.

# 3. Save. With `jekyll serve --livereload` running on :4000,
#    the site rebuilds in ~200 ms and the browser auto-refreshes.

# 4. Ship it.
git add _posts/2026-05-04-thoughts-on-rust.markdown
git commit -m "Add post: Thoughts on Rust"
git push

GitHub Pages picks up the push and rebuilds in 30–90 s.

Things worth knowing

• The filename is load-bearing. YYYY-MM-DD-slug.markdown isn’t a convention — Jekyll parses it. The date becomes page.date (overridable via the frontmatter date: field), the slug becomes page.slug and the URL fragment. A file named notes.md in _posts/ is silently skipped, no error.
• Frontmatter is YAML, with all of YAML’s quirks. Quote titles containing : or starting with [, &, *, ?. The date: value needs the timezone offset, set globally via _config.yml’s timezone:. If parsing fails, Jekyll prints a quiet warning and skips the post.
• layout: post wraps the body in Minima’s _layouts/post.html (title header, date, prev/next nav). Without it, you get raw content with no styling.

Drafts (work in progress)

Posts not yet ready to publish go in _drafts/ instead of _posts/, and don’t need a date in the filename:

mkdir -p _drafts
$EDITOR _drafts/half-baked-idea.markdown

Preview drafts locally — restart the server with --drafts:

bundle exec jekyll serve --livereload --drafts

When ready, move and rename:

mv _drafts/half-baked-idea.markdown _posts/2026-05-10-half-baked-idea.markdown

Drafts get page.date set to the file’s mtime, so they appear at the top of the local index until renamed. Without --drafts, Jekyll ignores _drafts/ entirely — both locally and on GitHub Pages — so it’s safe to commit drafts as backups, though most people gitignore _drafts/.

Images and other assets

Drop them in any non-underscored directory. The convention is assets/img/:

mkdir -p assets/img
cp ~/Pictures/diagram.png assets/img/

Reference in a post:

![Architecture diagram]({{ "/assets/img/diagram.png" | relative_url }})

The relative_url Liquid filter prepends site.baseurl. For a user site the baseurl is empty, so /assets/img/diagram.png resolves directly. But using the filter anyway means the same code works if the post is copied to a project site (where baseurl is /repo-name). Cheap insurance.

Underscored directories are reserved by Jekyll (_posts, _drafts, _layouts, _includes, _data, _site). Don’t create your own — they’ll be either consumed or excluded.

Categories vs. tags — the practical difference

Because categories show in the URL, changing them later breaks links. Tags are cheap to revise.

To get clean URLs without category prefixes, override the permalink globally in _config.yml:

defaults:
  - scope: { type: posts }
    values:
      permalink: /:year/:month/:day/:title/

Or per-post via frontmatter permalink: /thoughts-on-rust/.

Common pitfalls

A helper, if posts come often

Drop this in ~/.zshrc (or ~/.bashrc):

newpost() {
  local slug="${1:?usage: newpost slug-words [title]}"
  local title="${2:-${slug//-/ }}"
  local date="$(date +%Y-%m-%d)"
  local file="_posts/${date}-${slug}.markdown"
  cat > "$file" <<EOF
---
layout: post
title: "${title}"
date: $(date '+%Y-%m-%d %H:%M:%S %z')
categories: meta
---

EOF
  ${EDITOR:-vi} "$file"
}

Then newpost thoughts-on-rust "Thoughts on Rust" scaffolds the file with the right date and timezone, and opens it in your editor.