同花顺自选股分组功能如何设置与使用？

一、先看结论：分组是“研究记录”，不是“第二套持仓表”

同花顺自选股分组，本质是把一条越滚越长的自选清单按用途切开的整理动作。它真正的价值不在“多一个文件夹”，而在于让每一类观察对象拥有独立的生命周期和判断标准：短线跟踪的、长期底仓的、只做事件提醒的，一旦混在同一张表里，列表本身就会变成噪音源。本文以合规与数据留存为主线，先厘清边界，再给出桌面端、Android 与 iOS 的最短路径，最后落到迁移、兼容性对照与风险控制，目的是让你把分组当作一份可复核的记录来管理，而不是又一个随手堆放的抽屉。

需要提前说明的是，客户端界面会随版本迭代调整，本文涉及入口位置的描述，以截至当前最新版本的常见布局为准，具体请以你实际安装的客户端为准。凡是无法从公开信息确认的行为差异，文中会标注为“工作假设”或“经验性观察”，并配一套可自行复现的验证步骤，而不是给出确定性断言——这也是本文与“操作大全”式文章的差别所在。

二、功能定位：分组解决什么问题，又不解决什么

分组属于“列表组织”能力，不是策略工具。它只改变你看到哪些标的、按什么顺序看到，不改变行情数据本身，也不产生任何买卖信号。把这一点先钉住，后面很多取舍才判断得清楚：比如它为什么不该记录成本，又为什么不能替代预警。

实际使用中，分组主要化解三类摩擦。第一是噪音隔离：把几十只“随便看看”的股票和十几只“每天必看”的股票放在一起，翻页成本会持续上升，注意力也会被随机分配。第二是生命周期分离：一只股票从“观察”到“进入计划”再到“结束跟踪”，在不同分组里停留的时长不同，分组让这个迁移过程留下痕迹，而不是靠记忆追溯。第三是复盘与交接：当你要向同事或未来的自己解释“当时为什么关注它”，组名和你放进去的时间点，往往比记忆更可靠。

边界同样要说清楚。分组不是持仓管理，不记录成本与数量；它不是条件预警的容器，预警的触发条件需要单独维护；它也不是回测样本池，分组里的标的不会自动进入任何策略计算。经验性观察是：不少用户把分组当成“第二套持仓表”，结果两头数据都对不上，最后既不信持仓也不信分组。这类误用应该在开始时就避免，而不是等到数据打架再回头收拾。

至于“什么时候不该建分组”：自选股总量长期稳定在二三十只以内、且没有明显的观察阶段划分时，强行建组反而增加维护成本。分组的维护成本随组数上升，超过五六组以后，命名冲突和归类犹豫会明显变多——这是定性趋势，不是精确阈值，你可以用自己的实际使用频率来校准。

三、动手之前：先验证“组”与“股”的关系

在正式整理之前，建议花两分钟做一次小实验。它看起来只是一个动作，却直接决定你后面怎么迁移、怎么清理，甚至决定删除分组时该不该紧张。

验证方法（可复现）：在桌面端新建一个分组，命名为容易识别的临时名；把一只已经在默认自选里的股票加入该分组；随后回到默认自选列表，观察该股票是否仍然存在；最后到新分组里确认它是否出现。预期可观测结果有两种：一是同一标的可以同时出现在默认列表与新建分组中（视图切分），二是该标的从原位置消失、只在新分组里存在（归属移动）。两种结果对应两种数据模型，后续的清理和迁移策略完全不同。

这一节的目的不是给出结论，而是交给你一套自查方式。客户端行为会随版本变化，任何“绝对如此”的描述都不如一次两分钟的实测可靠；把结论记下来，第五节讲加入方式时还会用到它。

四、版本差异与入口盘点

同花顺的多端入口并不完全一致，差异主要集中在“分组管理”这个动作被放在哪一层。桌面端通常以自选股页面为主入口，分组切换条位于列表上方，管理动作多通过分组条上的新增入口、右键菜单或列表区域的右键菜单触达。桌面端真正的优势是批量操作：多选后一次性移动到目标分组，效率远高于逐只点选，这也是结构性调整优先放在桌面端的原因。

Android 与 iOS 受屏幕宽度限制，分组一般以横向可滑动的标签条呈现，管理入口多集中在标签条末端或页面右上角的编辑/更多区域。两端功能大体对齐，个别版本在排序与批量移动上的表现略有差别。遇到差异时，一个稳妥的做法是：结构性的调整（新建、重命名、排序、批量移动）优先在桌面端完成，然后回到手机端确认同步结果，而不是在手机上反复试错。

网页端的情况要单独说明。行情页面的自选股模块通常只提供查看与基础增删，分组的完整管理能力仍以客户端为主。若你需要在无客户端环境里核对分组结构，网页端适合做“只读校验”，不适合做批量改结构——把它当成一面镜子，而不是一把剪刀。

上表只描述结构性差异，不涉及具体版本号。如果你的界面与描述不一致，请以客户端的实际入口为准，并把差异记录下来——这份记录本身也是迁移时的重要参考。

五、最短操作路径：建组、加股、改名、删除

5.1 新建分组

桌面端的最短路径是：自选股页面 → 分组条上的新建入口 → 输入名称 → 确认。手机端则是：自选股页面 → 分组标签条末端或右上角编辑/更多 → 分组管理 → 新建 → 命名 → 保存。路径本身很短，真正值得花时间的是命名。

命名建议带上用途和时间，例如“观察-本季度”“事件-财报季”“底仓-长期”。这样即使几个月后回看，你也不需要靠记忆还原当时的意图。反过来，用“1、2、3”或“新建分组”“测试”这类名字，三个月后基本等于没有分组——因为名字里没有留下任何可用于判断的信息。

5.2 把股票加入分组

常见有三条路径：一是在新建分组时直接挑选标的；二是在自选列表里多选后执行移动或复制到目标分组；三是在个股详情页通过加入自选的入口选择目标分组。三条路径的结果可能不同，差别就在于“移动”和“复制”的语义——移动会让原位置消失，复制则保留。第三节那次实测的结果，正好用在这里判断你当前版本执行的是哪一种；若还没做，建议先补上再批量操作。

5.3 重命名与排序

排序看似是小事，实际影响注意力分配。经验性观察是：把使用频率最高的组放在手机端标签条最左侧、或桌面端列表最上方，能明显降低误点概率，因为大多数操作发生在列表首屏。重命名则建议遵循同一套命名规则，避免出现“观察-本季度”和“本季观察”并存的混乱——规则一旦松动，分组就会退化成第二份无序清单。

5.4 删除分组与回退方案

删除前先做两件事：确认组内标的的去向（是被连带移除，还是回到默认列表），以及在结构稳定期做一次留档。如果无法确认当前版本的删除行为，最稳妥的回退方式是“重建 + 重新加入”，这也意味着删除动作本身缺乏撤销能力。

六、数据同步：账号是前提，但不是保险

分组的跨端一致性依赖账号登录。用同一账号登录多端，结构通常会在联网后趋于一致；未登录状态下的新增只存在于本机，清理缓存或更换设备后可能消失。这也是为什么“换手机前先确认登录状态”应该写进迁移清单的第一条。

但账号登录不等于实时同步。同步更接近“最终一致”，而不是“实时锁”。两台设备在离线状态下分别改结构，联网后可能出现覆盖或合并的行为差异，具体表现因版本而异。验证方法：在 A 设备断网新建一个分组，在 B 设备同时修改另一个分组的名称，恢复网络后分别检查两端，记录哪一边的结构被保留。做一次这个实验，你就知道在自己当前版本上“谁赢”，后续操作也就有了依据。

由此得出两条操作纪律。第一，结构变更集中在单一设备上完成，其他设备只做查看，避免多点写入。第二，任何一次较大的结构调整之后，隔几分钟再打开另一端确认，而不是立刻假设已经同步成功——留一点时间给同步，通常比反复刷新更有效。

七、迁移步骤：换设备、换账号怎么搬

迁移的目标不是“把列表搬过去”，而是“把结构连同含义一起搬过去”。建议按六步执行，每一步都有明确的完成标志；做完一步再进下一步，出问题时也容易定位在哪一环。

1. 冻结：停止一切结构改动，记录当前组数、每组只数，形成一张简单清单。
2. 留档：逐屏截图，或导出清单；截图时把日期和组名一起拍进去，否则日后无法判断版本。
3. 校验云端：在新设备登录目标账号，等待同步完成，先只做查看，不做修改。
4. 重建：若结构未完整还原，按“先骨架后填充”的顺序建组：先把组名与顺序搭好，再逐组加入标的。
5. 抽样校验：抽取约一成的标的做比对，重点检查容易被忽略的组——通常是使用频率最低的那一组，问题往往就出在那里。
6. 清理旧环境：确认新环境稳定后再处理旧设备，不要提前删。

为什么不建议“新设备登录完就结束”？登录能带来列表，但自定义组名与分组顺序是否完整迁移，取决于账号侧的存储与版本兼容情况。经验性观察是：基础自选列表的迁移通常比较稳定，组名与顺序的还原度偶尔会有出入，因此抽样校验这一步不能省，尤其是组数较多的情况。抽样不必全量，但一定要覆盖那些你平时最少打开的分组——问题往往藏在注意力之外。

八、兼容性对照：哪些能力跨端一致

下表按能力维度对照，用于快速判断“这个动作该在哪一端做”。标记为“以实际版本为准”的条目，说明公开信息不足以确认一致性，需要你自己验证。

这张表的用法很简单：凡是标为“以实际版本为准”的行，先在小范围试一次，确认结果后再做批量操作。不要拿真实的自选结构当试验品——一次误操作的修复成本，通常远高于多做一次验证的时间成本。

九、合规与数据留存：为什么分组要“可审计”

这是本文的主线。自选股分组是个人研究工具，不构成任何投资建议，也不产生对外承诺；但当你把分组用于团队协作、内容生产或投研记录时，它就从“私人便签”变成了“需要能解释的记录”。所谓可审计，是指任何一次结构变更，事后都能说清楚是谁、在什么时候、为什么改的——它并不需要多重的工具，只需要一点前置的自觉。

落地到操作上，有三条低成本规则。第一，命名带语义：不用数字序号或默认名，用“用途 + 阶段”的组合，例如“跟踪-待验证”“跟踪-已建仓观察”，让组名自己解释自己。第二，变更成对留痕：建组和删组时同步更新一份外部记录，写明日期与原因。这份记录不需要多复杂，一张表格就够，但它的回溯价值远高于维护成本。第三，不要往组名里塞结论：像“必涨”“稳赚”这类表述既无助于判断，也会在你分享截图时带来不必要的合规风险。

协作场景要额外注意边界。把分组截图发给同事讨论属于正常沟通；若对外发布，需要说明这是个人观察清单而非推荐列表。若使用第三方工具处理自选数据，请遵循权限最小化：只授予必要范围，用完即撤，绝不在来源不明的页面输入账号密码。

十、风险控制：五类常见风险与对策

下面五类风险大多不是技术故障，而是操作习惯的副产品。按“现象—原因—对策”的顺序排列，便于你对照自查。

误删。现象是分组或组内标的突然消失。原因多为删除前未确认组的归属模型。对策是删除前先看组内标的去向，并在稳定期做一次截图留档；删除后的回退基本只能靠重建。

同步冲突。现象是两端结构不一致。原因是多点写入与离线修改。对策是结构变更集中到单一设备，改完隔几分钟再核对另一端。

数量上限。分组数量与每组标的数量通常存在上限，具体数值以客户端提示为准，不要凭印象假设。对策是在接近上限前先合并低价值分组，而不是等到无法新增才发现。

标的变更。更名、退市、代码调整之后，分组里的名称可能还是旧的，但含义已经变了。对策是在组内定期扫一遍，把失效标的清理出去；这类清理建议每季度做一次，成本很低。

账号安全。分组数据依附于账号。对策是启用可用的安全设置，不在公共设备上保持登录；如果必须在他人设备上查看，用完主动退出。

十一、故障排查：现象、原因、验证与处置

排查时有一个顺序建议：先确认账号与网络，再确认操作语义（移动还是复制），最后才怀疑版本兼容。这个顺序并非随意：账号与网络是前提，操作语义是高频失误点，版本兼容反而是最后才需要怀疑的因素。多数“分组丢了”的情况，实际发生在第一步或第二步。

十二、适用与不适用场景清单

适合使用分组的场景包括：需要多阶段跟踪同一批标的；按事件驱动组织观察对象（例如财报季、行业会议）；需要向他人交接研究思路；需要为自己的复盘保留结构痕迹。这些场景的共同点是“结构本身携带信息”，分组名和顺序能替你说话。

不适合的场景同样明确：自选总量很小且没有阶段划分；只是一次性临时观察，看完即删；需要严格权限隔离与操作日志的机构场景——这类需求应该交给具备相应合规能力的专业系统，而不是依赖个人客户端的自选股分组。把不适用场景想清楚，比多建几个组更有价值。

十三、最佳实践检查表

把前面的内容压缩成一份可执行的清单，便于在整理前后各过一遍：整理前看前半段，确认前提；整理后看后半段，确认收尾。

• 建组前先做“组与股关系”的两分钟验证，再决定迁移策略。
• 组名统一采用“用途 + 阶段”格式，不使用数字序号与默认名。
• 结构变更集中在单一设备完成，其他设备只读。
• 结构调整避开行情剧烈波动时段。
• 删除任何分组前，先截图或导出留档。
• 换设备按“冻结—留档—校验—重建—抽样—清理”六步执行。
• 每季度清理一次失效标的与低价值分组。
• 分享截图前检查组名中是否存在结论性表述。
• 第三方工具遵循权限最小化，用完即撤。

十四、常见问题（FAQ）

十五、写在最后：下一步做什么

回到最初的问题，同花顺自选股分组的核心结论可以归纳成三句话：它解决的是列表组织与观察阶段分离的问题，不承担持仓管理和策略计算；它的跨端一致性依赖账号与同步，而同步是最终一致而非实时锁；它的长期价值取决于你是否把结构变更当作可复核的记录来对待。

如果你准备动手，建议按这个顺序推进：先花两分钟做“组与股关系”的验证，再按“用途 + 阶段”的规则重命名现有分组，然后在桌面端完成一次批量整理并截图留档，最后回到手机端确认同步结果。整套动作预计在半小时以内可以完成，却能显著降低后续迁移和误删的成本。客户端界面仍会迭代，入口位置可能再次移位，但“先验证、再批量、后留档”这个顺序相对稳定。

若你处在团队协作或内容输出场景，请在完成整理后补一份简短的外部记录，写清楚组名含义与变更日期。这份记录不会自动生成，但它决定了半年后的你还能不能读懂今天的分组。