爱范儿出门前看了一眼明天的日程表，COSCon‘25 和 Apache Pulsar 的专场就摆在周末那条横线上。海报上那句“这么近，那么美，周末到海淀”，看上去是借了句文旅口号改了个地名，但放在技术人身上，这句话其实很写实——从西二旗到中关村，从五道口到学院路，海淀本来就是许多写代码、聊架构、搞开源的人日常通勤的范围。明天这种日子，与其躺在家里刷消息流，不如去现场跟人坐下来聊一上午。
这篇东西不是主办方发布的官方参会通知，而是我作为一名长期参与开源技术社区的技术从业者，帮你做的一份“带脑子去参会”的清单。既然标题里出现了 Pulsar，我尤其会站在 Apache Pulsar 社区参与者的角度来写：哪些环节值得听、现场怎么跟项目维护者打交道、带什么问题去现场才不算白跑一趟。无论你已经抢到票、还在犹豫要不要去，还是被朋友拉去“凑人头”，应该都能从里面找到点有用的东西。
- 周末去海淀参加这场会，不是在“赶场子”
1.1 “这么近，那么美”背后的问题：开源大会为什么值得出门
现在这个时代，想听技术分享其实不用出门。大会结束之后，PPT会流出来，视频回放会挂到网上，文字实录可能比演讲者自己讲得都清楚。那为什么还要在周末专门跑一趟海淀？我的答案很直接：技术内容可以线上获取，但人与人的连接不能。
代码仓库里的 issue 是异步沟通，邮件列表里的讨论是异步沟通，只有线下的会场是同步沟通。你在 issue 里跟一个项目维护者来回对话三个月，抵不上在现场面对面聊十分钟。开源协作的内核是“陌生人之间建立信任”，而信任的建立效率，线下远高于线上。我认识不少开源项目的 maintainer，很多人之间的合作从一句“上次会上见过你”开始，之后在 GitHub 上再打交道，语气都会明显不一样。
“周末”这两个字也很关键。工作日的大会，很多是公司派出来“出差”的人，议程排满、背着 KPI、听完就走；周末的开源大会，意味着大部分人是自己选择来的——自己报名、自己买票、自己坐车过来。这个微妙的差别决定了场子里的氛围：没有人是被迫坐在这里的，大家天然带着好奇心和交流欲。技术会场一旦有了这种底色，很多原本需要寒暄半天才能打开的话题，三句话就能聊到正题。
还有一个容易被忽略的点：开源大会的信息密度不在于台上的幻灯片，而在于 slides 之外的内容。你在 keynote 里听到的往往是项目愿景，但你在茶歇时遇到一位正在生产环境里跑 Pulsar 的 SRE，他随口说的一句“我们当时把刷盘参数调了一下，写入延迟降了一个数量级”，这种信息不会出现在任何官方议程里。它只出现在线下，且只出现在你愿意开口搭话的时候。
1.2 别把 COSCon 当成一场“大型讲座”
很多人第一次参加这种会议，习惯性地把它理解为一场普通技术大会：拿着议程表，从早到晚把每个时段都排满，坐在后排记笔记、拍 PPT，一天下来收获最大的是手机相册和录音文件。这不是参会，这是换个地方看视频。
我的建议是先做减法。挑当天你真正感兴趣的演讲，两到三场足矣，剩下的时间用来逛展区、听闪电演讲、跟人聊天，甚至只是找个座位旁听别人的对话。技术大会里的展区和过道，才是信息密度最高的区域。举一个我自己的例子：有一年我在某个消息中间件展台前随口问了一句“你们这版本在跨机房场景下有没有遇到脑裂问题”，结果旁边排队的一位工程师直接接话，说他们团队踩过这个坑，然后把整个排查过程讲了十分钟。这个问题我在线上论坛问了很久都没有得到这么完整的答案。
所以，如果明天你打算去 COSCon’25，请先调整心态：你去的不是一个讲座现场，而是一个由开源项目、社区成员和用户组成的临时集市。这个集市里最有价值的商品不是贴纸和帆布袋，是那些愿意跟你认真聊十分钟的人。
- COSCon 这类会议现场，最容易被忽略的三件事
2.1 台上的“分享者”和台下的“你”没有距离
COSCon 的全称是中国开源年会，它的气质跟很多商业技术大会不同：大部分议题是从社区征集中产生的，分享者不是被厂商市场部包装过的专家，而是真正在写代码、在维护项目、在生产环境里折腾过的人。这意味着你在散场后走过去跟演讲者搭话，完全不会遭遇那种“不好意思，老师要赶下一场”的尴尬。
我见过太多人在这种场合害羞。他们觉得演讲者很忙，不好意思多问。实际上，分享者站上演讲台的最大动机就是“希望自己的经验被更多人用上”，有人来追问细节，他们高兴还来不及。尤其开源项目的维护者，他们的核心诉求之一就是获得来自用户的真实反馈——你是把项目用在了什么场景？遇到了什么问题？哪个功能你特别希望下一个版本支持？这种对话对维护者来说是最宝贵的输入。
记住一个原则：在一场开源大会上，你不需要“讨好”任何一个分享者。你带着具体的使用场景去交流，就是对他最大的尊重。
2.2 提问的质量，决定你收获的质量
每次大会的圆桌或 Q&A 环节，总有人站起来问那种没有任何信息量的问题，比如“你们这个项目跟 XX 项目比有什么优势”。这类问题不是不能问，而是太宽泛，对方只能给你一个官方回答。
更好的提问方式是：“我目前在做一个 XX 类型的系统，最核心的痛点是 XX，我看了你们项目的文档，想确认一下它能不能……” 这类问题天然带着上下文，对方完全可以基于你的场景直接给出判断，甚至告诉你“如果你是这个场景，我不建议你用它”这种坦诚但极有价值的答案。
如果你对项目还不够熟，可以先问自己三个问题再来现场：这个项目解决什么问题？我现在的系统有没有同样的问题？如果引入它，我需要付出什么代价？把这三个问题想清楚，你在现场听任何分享都会比别人多接收一倍的信息。
2.3 展台面前别只盯着周边
COSCon 的展区会有很多开源项目摆摊，桌上通常堆着贴纸、T恤、甚至技术书。很多人走过去拍张照、拿个周边就走了，这非常可惜。展台前站着的往往是项目的活跃贡献者或社区运营成员，他们是整个会场里最容易接触到的“活文档”。
逛展台时我习惯先扫一眼项目名称，挑出与自己工作相关的两三个，然后上去直接说自己的使用场景，问对方当前版本有没有已知的坑、社区的 roadmap 里有什么计划。如果你自己也在做开源项目，也可以交换想法，大部分人会非常乐意聊聊技术选型上的取舍。至于周边，把它当成聊完之后的纪念品就好，顺序不要反了。
- 如果你是冲 Pulsar 来的，建议把注意力放在这几个问题上
3.1 Apache Pulsar 到底解决的是什么问题
Apache Pulsar 是一个云原生分布式消息流平台，最初由 Yahoo 开发，后来捐献给 Apache 软件基金会，并在 2018 年成为顶级项目。如果要一句话讲清楚它做什么：它是一个可以承载海量消息的路由系统，让不同服务之间通过消息完成解耦，同时保证消息不丢、不重、可以回溯。
消息队列这个领域，很多人熟悉 Kafka。Pulsar 经常被拿来和 Kafka 对比，两者的定位也确实有重叠。但 Pulsar 最核心的设计差异是“计算与存储分离”：它的消息处理层 Broker 是无状态的，而消息存储层交给 Apache BookKeeper 负责。这个听起来很抽象，我用餐厅来类比。
假设一家餐厅既有后厨又有仓库，传统架构下后厨和仓库绑定在一起，客人多了想多炒几个菜，厨房却放不下更多食材。Pulsar 的架构是把后厨和仓库拆开：炒菜窗口可以随意增加，仓库可以独立扩容。这就是为什么 Pulsar 在扩缩容和资源利用率方面有天然优势——因为计算节点不需要搬运数据，新增一个 Broker 的代价很低。
另一个值得提的是分层存储。Pulsar 可以把老消息从高性能存储自动卸载到便宜的对象存储，比如 S3 或者阿里云 OSS，这让它保留了“消息即日志”的能力，同时不用把所有历史数据都放在昂贵磁盘上。对很多有审计需求或需要重放历史事件流的系统来说，这个能力非常实用。
3.2 如果你是第一次接触 Pulsar，听演讲时先认住这些词
如果你此前只用过 Kafka 或 RabbitMQ，明天在 Pulsar 专场可能会被几个术语卡住，我提前列一下：
- Brokers：Pulsar 的计算层，负责接收请求、管理 topic 元数据，本身不存数据，所以可以快速扩缩容。
- Bookies：BookKeeper 集群里的存储节点，真正把消息落盘的地方。
- Topic：消息通路的基本单位，生产者往 topic 发消息，消费者从 topic 收消息。
- Subscription：订阅模式，Pulsar 的消费模型比很多传统 MQ 更灵活，支持独占、共享、故障转移、Key 共享等多种模式。
- Multi-tenancy / 多租户：在同一个集群里隔离不同团队或业务的数据与流量，靠 tenant 和 namespace 两层结构来管理。
- Geo-replication / 跨地域复制：在多个机房或地域之间自动同步消息，是构建多活架构的利器。
- Tiered Storage / 分层存储：把历史数据卸载到廉价的冷存储，在成本与查询能力之间做平衡。
- Pulsar Functions：在 Pulsar 内部直接跑轻量级处理逻辑，很多场景不需要额外部署一套流处理引擎。
如果你明天听完一场分享，能用自己的话解释清楚“Brokers 为什么可以无状态”，我觉得这一趟就已经值回票价了。
3.3 向维护者提问时，比“XX 和 XX 哪个好”更有价值的问题
如果你打算在 Q&A 环节向 Pulsar 的维护者提问，我建议把问题从“优缺点对比”改成“场景决策类问题”，比如：
- “我当前业务需要保留 90 天消息回溯，如果用 Pulsar 分层存储，性能拐点大概在什么位置？”
- “从 Kafka 迁移到 Pulsar，兼容层方案在生产环境踩过最深的坑是什么？”
- “在多个 region 做异地多活时，Pulsar 跨地域复制的 RPO 能做到什么程度？”
- “如果一个 topic 的 partition 数规划失误，后续调整的成本到底有多大？”
- “社区下一个大版本的 roadmap 里，你最期待的功能是什么？为什么？”
这些问题没有标准答案，但恰恰能帮你判断这个项目适不适合自己的场景，也能让维护者了解你的实际需求，一举两得。
- 出门之前，把这几件事在周五晚上就做掉
4.1 上周五晚上做好的三件事
不要高估自己第二天早上的行动力。既然活动就在明天，今晚其实已经需要做一些准备工作了。第一件，把电子票或参会二维码提前截图保存，不要等到会场门口才打开那个死活加载不出来的小程序。第二件，确认自己的身份证件带好了，部分场地需要核对身份信息才能进入，别在这种地方耽误时间。第三件，给所有电子设备充好电，包括手机、充电宝、如果打算拍照的相机，同时把会议议程再快速看一遍，在脑子里大概圈出三个“必去”的时间点。
另外，我对第一次参加这类活动的朋友有个额外建议：今天先查一下活动场地周边有没有合适的餐饮。会场里的午餐通常要排队，如果你愿意多走几步路，在附近找个地方安静吃个午饭，顺便整理一上午的笔记，远比挤在排队人群里更舒服。
4.2 海淀很大，导航别只搜“海淀”两个字
海淀的地域范围比你想象中大得多，从学院路到西北旺，开车可能都要一个小时。千万不要凭感觉觉得“反正就在海淀”，直接搜那么大一个区名就出门。最好今晚就把具体的场馆地址看一遍，提前规划好交通方式。
如果你打算开车，我需要提醒一句：海淀很多科技园区和高校周边停车资源非常紧张，活动当天车位大概率不够用。与其在停车场门口排半小时队，不如优先考虑公共交通。如果场地确实偏远，建议你提前约好车，或者跟同城的朋友拼车，分摊成本也降低焦虑。如果选择地铁出行，从出站口到会场门口的那段路也最好提前看一眼地图，别在户外多绕冤枉路。
还有一件小事：明早给自己多留 30 分钟缓冲。现场签到往往比想象中慢，安检、排队、找会场、跟熟人打招呼，这些时间成本都要算进去。宁可早点到，在展区找个地方坐着喝杯水，也比踩着点冲进去、满头大汗坐下来要舒服得多。
4.3 参会背包带什么，不带什么
一天参会下来，背包里的东西可以直接决定你的舒适度。我带过太重的东西，结果到下午肩膀酸痛，注意力直线下降。根据我自己的经验，列了一个清单供你参考：
- 必备：身份证件、手机、电子票二维码截图、充电宝、充电线、纸巾。
- 建议：轻薄笔记本（或平板/纸笔二选一）、水杯、一件外套（会场空调通常很足）。
- 看情况：名片（或提前准备好电子名片）、一副降噪耳机（散场路上想安静整理思路时有用）。
- 别带：大行李箱、好几本厚重的书、一堆不必要的数据线、折叠椅这种明显不现实的东西。
背包尽量选择双肩包，解放双手，这样你在展区要扫码、要握手、要拿资料时才不会手忙脚乱。外套一定要带，大型场馆的中央空调往往冷得不像夏天，这一点几乎每场活动都有人被冻到。
- 明天现场一整天的实操走位，可以参考这个节奏
5.1 入场之后先别急着冲主会场
如果你到得比较早，我的建议是别随着人流直接涌进主会场占座，而是先花二十分钟把展区从头到尾逛一遍。这个时间段展台没人跟你抢着聊，维护者精力也最充沛，聊出来的信息量比下午高很多。
主会场的大会主题演讲适合快速了解一场开源活动“今年在关心什么”，但如果你想拿到具体、可落地的技术经验，分会场的小主题演讲才是重点。小场子的分享者通常只面对几十人，互动感强，提问也更从容。需要注意的是，热门场次散场时会有一波“跨场人流”，如果你接下来要去的场子比较远，最好提前 1-2 分钟离场。动作稍微早一点，能帮你占到一个视野更好的位置。
5.2 中午是最值钱的社交时间，别只跟同事坐一桌
很多人的误区是中午跟一起来的同时吃饭，然后聊了一中午与大会无关的话题。这太浪费了。开源大会的午饭时间是一个天然的“陌生人社交场”，共同话题已经摆在那里，只要你说一句“旁边有人吗”，对方通常都会接话。
我有一个百试不爽的开场方式：让对方推荐今天他听过的印象最深的一场分享，或者问他最关注哪个项目。这个问题的门槛很低，人人都答得上来；答完之后你就可以顺着往下问“为什么印象深”“他讲了什么让你意外的东西”，对话自然就展开了。一顿午饭下来，你不仅能知道今天哪些场次值得听，还能通过对方的朋友圈认识更多同领域的人。
如果你性格偏内向也没关系，可以坐在一个不那么挤的位置，然后观察周围谁在谈论你感兴趣的技术点，找个合适时机插一句“不好意思，刚才听你说到 XX，我也在做相关的东西”。在开源大会上，这句话比任何精心设计的破冰话术都管用。
5.3 当天新加的微信好友，记得当晚就整理
会议结束、回到家的那个晚上，是整场活动收益的“定盘星”。我见过太多人当天加了二十个微信好友，一周后就完全想不起来谁是谁了。这不是社交能力的问题，而是没有在记忆尚存时做一次整理。
晚上我会做这么几件事：把当天加的每个人都加上一条备注，记录在哪个场景认识、聊了什么话题、当时为什么觉得值得加；把拍下的 PPT 照片导入相册，按场次建文件夹；如果录音了，可以顺手剪出几段自己标记过的片段。如果当天有让你印象很深的分享或对话，趁热打铁写个短帖子发在朋友圈或博客里。写作不需要很长，甚至三百字就够了，它的作用是逼你把碎片信息转化成自己的语言，这个过程本身就是一次吸收。
另一个容易被忽略的细节是：给当天帮助过你的人发一条有内容的消息。不要群发“很高兴认识你”，而是写清楚“我是早上问过你 Pulsar 配置参数的那位，感谢你的建议，我回来后按你的思路做了调整……” 这种消息才是真正有价值的社交货币。很多开源项目的协作机会，就是从这样一条消息开始的。
我在实际参加这类开源大会之后，有一个很深的体会：那些觉得“开会没意思”的人，通常只把会议当成一个接收信息的场所；而那些每次都有收获的人，则把会议当成连接资源的场所。两者的差别不在于听众多聪明，而在于出发之前想没想清楚“我为什么去”。明天如果你正好也在海淀，希望你在会场能够主动开口，跟坐在旁边的人聊聊他为什么来这里。你会发现，那个问题的答案，往往比任何议程表都精彩。