那天我在整理内容发布入口时，先想到的是一个很自然的问题：如果同一个身份要同时管理视频号、抖音和小红书，是不是应该给每个平台都准备一套浏览器？看起来这样最清楚。每个平台一个窗口，互不干扰，出了问题也容易定位。
但当我把这个问题继续往下想，发现它真正难的地方不在“开几个窗口”，而在于浏览器里的登录态究竟属于谁。平台只是入口，身份才是权限边界。如果把平台当成隔离单位，很容易为了整齐而复制出许多浏览器；如果把身份当成隔离单位，同一身份下的多个平台反而可以自然地放在同一个实例里。
这次讨论最后形成了一个简单但很重要的判断：同一个身份，使用同一个浏览器实例，在里面按平台开标签页；不同身份，才需要独立的浏览器实例。这个判断看似只是整理窗口，实际上是在给登录态、发布动作和后续自动化划边界。
我一开始把平台当成了隔离单位
事情的起点，是希望以后说一句“上传到某个平台”，系统就能自动找到对应的入口。最初的直觉是，一个平台配一套专门浏览器，平台之间互不相干。这样做的好处很明显：页面名称容易记，操作时不容易把视频发错地方，也不用在多个网站之间来回切换。
可是，这个方案很快暴露出一个问题。同一个身份要管理多个平台时，复制浏览器并没有增加真正的安全边界。它只是把相同的登录状态、收藏入口和操作习惯重复了几份。窗口变多了，身份边界却没有变得更清楚。
浏览器隔离首先应该回答“是谁在操作”，而不是“正在操作哪个平台”。
这句话把问题重新排了一次顺序。视频号、抖音和小红书只是不同的发布渠道；登录态、权限和内容归属，才决定一次操作应该落在哪个环境里。只要它们都属于同一个身份，就没有必要为了平台名称各自复制一份用户目录。
平台不同，不等于身份不同
后来我把场景拆开看：同一个身份要连续处理一条内容，可能先打开视频平台检查素材，再切到另一个短视频平台填写标题，最后去生活方式平台确认封面。它们的页面不同、字段不同、发布按钮也不同，但这些差异都发生在同一个身份的工作范围内。
如果为每个平台各开一个浏览器实例，表面上看是清晰，实际却会增加维护成本。登录过期要分别处理，收藏入口要分别维护，窗口之间还可能留下多个重复页面。更麻烦的是，当自动化入口以平台名命名时，使用者可能误以为“平台入口”天然等于“身份入口”，从而忽略发布前的身份确认。
如果不处理这个边界，后面会出现的问题不是少开或多开几个窗口，而是登录态越来越难判断。某个平台的页面看起来还在，实际可能已经切到了另一个身份；某个入口虽然名称正确，当前标签页却停留在错误的账号。到了真正发布的时候，错误才暴露出来，而内容往往已经进入不可逆的发布流程。
因此，我更愿意把浏览器看成身份容器，把标签页看成平台入口。容器负责保证“是谁”，标签页负责说明“去哪里”。两者职责不同，才不会因为平台数量增加，就不断复制整套环境。
不同身份才需要真正分开
讨论中还有一个关键变化：后来创建了另一个身份实例，用来承载另一组账号。这个动作让我更清楚地看到，什么才值得单独隔离。
不同身份之间，登录态不能混用，发布记录不能混用，自动化也不应该默认共享同一组会话。如果把它们放在同一个浏览器用户目录里，哪怕平时靠标签页区分，仍然可能在切换过程中留下错误的 Cookie、历史页面或自动填充信息。人记得住当前打开的是哪一页，不代表系统就能永远记住这页属于哪个身份。
真正需要独立实例的，是权限和归属不同的身份，而不是网站名称不同的平台。
我选择按身份划分实例，是因为它能把最危险的错误挡在更早的位置。进入某个实例时，默认就已经进入对应身份的工作空间；实例内的标签页只负责平台切换。即使 1 天要处理多个平台，也不需要在身份之间来回搬运登录态。
这里的“身份”不一定要写成公开名称。它可以是个人品牌、企业账号、客户项目，或者任何一组不能混用的权限集合。只要两组账号在内容归属、授权范围或发布责任上不同，就应该当成不同身份处理。
最容易误判的错误捷径
最容易误判的错误捷径，是每个平台都复制一套浏览器，觉得窗口越多，隔离就越充分。这个做法不一定马上出错，甚至在短期内会让人感觉很有秩序，所以更难被发现问题。
它的问题在于，把“看起来分开”当成了“权限真的分开”。同一个身份被拆成多个实例后，维护动作会变成重复劳动，入口也会分散。更重要的是，真正需要确认的事情——当前身份是否正确——没有被流程强制提醒，只是被藏在一堆窗口名称里。
另一个错误捷径，是把不同身份混在同一个用户目录里，然后靠标签页名称区分。这个方案更省事，却把风险推给了人的记忆。标签页可以重命名，窗口可以被关闭，浏览器也可能恢复上次页面。只要有一次误判，后面的标题、封面和发布内容就可能落到错误的账号上。
我没有选择这两种方式，是因为它们都在用视觉上的整齐替代真正的边界。一个好的隔离方案，不应该只让人“看着不容易混”，还应该让系统本身尽量不允许混用。
把身份守卫放在发布动作之前
确定实例和标签页的关系以后，流程还不能停在“开对窗口”。发布前必须有一个身份守卫：确认当前浏览器实例、当前平台页面和预期身份一致，再继续填写和发布。
这个确认不需要做得复杂，但要放在正确的位置。进入实例时先确认身份，打开平台标签页时确认入口，真正点击发布前再确认一次当前会话没有跳转或失效。三次确认解决的是不同问题：第一次防止进错容器，第二次防止平台走错入口，第三次防止登录态在中途变化。
如果某个平台提示重新登录，或者页面显示的身份与预期不一致，就应该停在发布之前处理，而不是抱着“应该没问题”的心态继续。内容发布的风险不是打开页面失败，而是成功发布到错误的地方。越接近不可逆的动作，身份确认越不能依赖记忆。
发布完成以后，我会关闭重复打开的页面，但保留稳定的平台入口。这样做不是为了让窗口看起来干净，而是为了减少下一次操作的分叉。入口越稳定，越容易在进入后立刻确认身份；重复页面越多，越容易把旧会话误认为当前会话。
一套可以复用的分层方法
这次形成的方法，可以概括成“身份分实例，平台分标签页，动作前做守卫”。它适合多平台内容发布，也适合后台管理、客服、数据查看等需要同时使用多个网站的工作。
第一步，先列出身份边界。不要先数有几个网站，而要先确认哪些账号的权限、内容归属和责任不能混在一起。每一组独立身份对应一个浏览器实例。
第二步，在同一个身份实例内整理平台入口。每个平台只需要一个稳定标签页或书签入口，名称写清平台用途，但不要把平台名称误当成身份名称。这样既能复用登录态，也能避免为每个平台重复维护环境。
第三步，给发布动作加身份守卫。进入实例时确认身份，进入平台时确认页面，发布前确认当前会话。发现登录过期、身份不符或页面异常，先处理状态，再继续发布。
第四步，发布后做轻量收口。关闭重复页，保留稳定入口，记录必要的异常。不要因为一次操作成功，就默认下一次仍然会使用同一个会话；稳定流程需要重复确认关键边界。
这个方法的价值，不是让浏览器永远只有最少的窗口，而是让每个窗口都有明确职责。身份决定隔离层级，平台决定入口层级，发布动作决定校验时机。以后即使增加新平台，也只是在对应身份里增加一个入口，不必重新设计整套浏览器结构。
下次我会怎么做
下次遇到“一个身份要发多个平台”的需求，我会先问自己：这些平台是不是属于同一组权限和内容归属。如果是，就使用同一个浏览器实例，在里面按平台开标签页；如果不是，就先建立新的身份实例，再在新实例里整理平台入口。
我不会再把“每个平台一套浏览器”当成默认答案。平台数量增加时，先看身份是否增加；身份没有增加，隔离层级就不应该跟着膨胀。这样可以保留登录态复用的便利，也把不同身份之间最容易发生的串用风险挡住。
这件事让我重新意识到，工具的秩序不是窗口越多越好，而是边界放在真正会出错的地方。表面上我是在整理浏览器，实际上是在整理责任：谁能发布什么，在哪个环境里发布，发布前必须确认什么。一个流程成熟的标志，不是它能打开所有平台，而是下一次操作时，不需要靠临场记忆才能避免发错账号。