同花顺自选股分组功能如何设置并支持快速切换查看？

在同花顺里，同花顺自选股分组是把几十上百只标的按用途切开的基础能力：短线盯盘、中线跟踪、复盘归档各占一组，切换分组就等于切换看盘视角。它的价值并不在“能分组”本身，而在于三件事能否同时成立——切换够快、数据留得住、事后查得到。换句话说，它更像一套把注意力分层的操作框架，而非给股票贴标签的装饰功能。本文按“定位—路径—迁移—风险”的顺序展开，既给可直接照做的步骤，也说明每一步为什么这样做、什么情况下不该这样做。

一、分组功能到底解决什么问题

自选股列表一旦超过二十只，信息密度就会从“参考”变成“噪音”。分组的第一层作用是降噪：把同一屏里互不相关的标的按决策周期拆开，让每次打开自选页看到的都是当下要处理的那一批；第二层作用是留痕：分组结构本身记录了你在某个时间点的关注范围，半年后回看，能大致还原当时的判断边界。降噪解决的是当下一刻的注意力分配，留痕解决的是事后回溯，两者缺一，分组就容易退化成一次性的界面设置。

这也是本文把“合规与数据留存”作为主线的理由。分组看上去只是界面偏好的设置项，但它实际上是一份持续更新的关注清单，属于典型的个人偏好数据。它不会替你下单，也不构成任何投资建议，但它的增删改如果能被自己复核，日常复盘的成本会明显下降——你不需要凭记忆回忆上周在盯什么，打开分组就能对上号。

三个高频场景，对应三种分组粒度

把上面两层作用落到日常操作上，大致会分化出三种使用节奏，它们的差别不在功能，而在分组被预期活多久。

• 开盘前扫一眼：把次日要盯的三五只票放进临时组，开盘集合竞价阶段只切这一组，避免被其他标的的涨跌分散注意力。
• 收盘后回看：把当日异动但未参与的标的放进“复盘组”，周末统一清理，避免临时起意的标的长期占据主列表。
• 长期跟踪：把有基本面逻辑、需要按季度跟进的标的单独成组，平时几乎不看，只在财报窗口期打开。

这三种粒度的差异在于“生命周期”。临时组的寿命通常只有一两个交易日，复盘组按周清理，长期组按季度更新。分组的数量不必多，但每一组都应当能回答一个问题：我为什么把它放在这里。回答不了的分组，本质上是一个没有索引的抽屉——东西放进去容易，想再找出来就得全部倒一遍。

二、边界辨析：分组不是板块，也不是预警

实际操作中最常见的误解，是把自选股分组和行情软件里的板块、行业分类混为一谈。板块由交易所与数据服务商定义，所有人看到的是同一套口径；分组由你自己定义，只对你自己可见。前者用于横向比较，后者用于纵向管理。用分组去做行业统计，样本会随着你的个人偏好漂移，结论没有可比性。

另一层边界是“分组不会触发任何提醒”。把一只股票放进某个分组，只是改变了它在界面上的归属位置，不会产生推送、不会形成条件单、也不会改变行情订阅关系。如果你的需求是“到价提醒”，那属于预警或条件单的范畴，需要单独设置，两者不要互相替代——用分组代替预警，最常见的后果是错过本该被提醒的价格窗口。

概念	本质	数据归属	典型误用
自选股分组	用户自定义的标的集合	个人账号与本地缓存	当成交易流水或持仓记录
行业/概念板块	数据商统一口径的分类	公共数据	用自建分组替代行业统计
预警 / 条件单	基于价格条件的触发式监控	本地或服务端，视设置而定	以为放进分组就会收到提醒

把这三者分开之后，取舍就清晰了：需要横向对比行业强弱，用板块；需要“到点告诉我”，用预警；需要“把注意力收窄到这一批”，才用分组。判断标准很简单——如果这个需求换成别人来做，结果应该一样，那它就不该用分组实现。

三、版本差异与界面演进：路径为什么会不一样

同花顺在多个终端上并行迭代，桌面端、Android、iOS 的自选页布局并不完全一致，历史上也调整过分组入口的位置。较新的布局里，分组通常以横向标签栏的形式出现在自选列表的顶部或底部；较早的布局则可能把分组折叠进“管理”或侧边面板中。因此本文不给出固定坐标，而是给出一条稳定的定位思路：先进入自选股页面，再寻找页面内与“分组”“管理”“编辑”相关的入口。

这种不确定性并不影响可操作性，只要把“找不到入口”当成一个需要排查的现象，而不是功能缺失。验证方法很直接：在自选页内逐一点开可见的“管理”“编辑”“更多”类按钮，观察是否出现分组列表。示例：依次展开这几个入口后，若其中任一项出现带分组名称的列表，说明入口就在这里；若全部展开仍无分组区域，再考虑版本过旧的可能。

四、桌面端最短路径

桌面端的优势是鼠标右键与批量操作，适合一次性把分组结构搭好。下面三条路径按“建组—归组—切换”的顺序给出，每一步都附上失败时的回退方式，遇到界面对不上时不必从头试错。

4.1 新建与重命名

1. 在左侧导航栏点击“自选股”（部分版本显示为“我的自选”），进入自选列表页。
2. 在页面内的分组标签区域找到末尾的“+”或“新建分组”入口；若标签区域不可见，尝试展开页面内的“管理”或“编辑”按钮。
3. 输入分组名称并确认。建议名称控制在六到八个汉字以内，便于在标签栏完整显示。
4. 需要改名时，在分组标签上右键，或进入分组管理面板后选择重命名。

为什么建议短名称：标签栏是横向排布的，名称过长会被截断成省略号，切换时反而增加了辨认成本。什么时候不该急着改名：如果分组已经稳定使用了一段时间，改名会削弱历史截图的可比对性，此时更稳妥的做法是新建一组、逐步迁移，而不是原地改名。换句话说，改名的成本不在操作本身，而在它会让过去留存下来的对照关系失效。

4.2 把已有自选股归入分组

在自选列表中对目标股票点击右键，通常可以看到与“移动到分组”“加入分组”相关的菜单项，选择目标分组即可。若菜单中没有该选项，可先进入目标分组，再在该分组内通过“添加自选”逐个加入——这条路径更慢，但兼容性更好，适合在版本差异不明时使用。

批量归组时有一个容易被忽略的细节：一只股票是否可以同时存在于多个分组，取决于客户端的具体实现。经验性观察：多数版本的“移动到分组”属于移动语义，执行后原分组中不再保留该标的。验证方法很直接——把同一只股票先放入 A 组，再执行一次“移动到 B 组”，随后切回 A 组查看它是否仍在。这个动作只需十几秒，却能避免后续反复补录，也能让你提前知道自己该用“移动”还是“添加”。

4.3 快速切换的三个入口

• 标签栏直点：最常见也最快，点击标签即完成切换，适合分组数量在十个以内的情况。
• 分组下拉：分组过多导致标签溢出时，标签区末尾会出现展开入口，以下拉列表形式选择。
• 自选页内的分组管理面板：适合低频但需要跳转较远分组时使用，步骤多一步，但不受标签栏可见范围限制。

这三个入口的适用条件其实是互斥的：分组少时标签栏最快，分组多时下拉更稳，跨组跳转时管理面板最省心。切换效率的关键变量不是手速，而是分组数量。当分组超过八到十个，标签栏开始溢出，每次切换都要多一次展开动作。经验性观察：把常用分组控制在五到七个，其余分组按项目制临时创建、用完即删，整体切换效率会有可见提升。这个结论是定性的，具体体感因屏幕尺寸与分组命名长度而异。

五、移动端路径与平台差异

移动端的自选页空间更紧张，分组通常以顶部横向滚动标签的形式呈现。Android 与 iOS 的交互骨架接近，差异主要体现在长按菜单与手势习惯上，下面分别说明。

5.1 Android

1. 打开 App，底部导航进入“自选”。
2. 在页面顶部的分组标签条向右滑动，找到末尾的“+”或点击“编辑”“管理”。
3. 输入分组名，确认保存。
4. 加入标的时，在自选列表中对目标股票长按，查看是否出现与分组相关的菜单项；若没有，进入目标分组后使用页面内的“添加”按钮。

5.2 iOS

iOS 端的整体流程与 Android 基本一致，入口同样位于自选页顶部的分组区域。需要留意的是，iOS 上的长按菜单与左滑操作承担了不同的语义，左滑往往对应删除自选，长按才更可能对应分组相关操作。操作前先确认手势对应的功能，可以避免误删；在不熟悉当前版本的情况下，先对一只不重要的标的试一次，是代价最低的做法。

5.3 两端的差异点与共同风险

差异集中在三处：分组排序是否支持拖动、长按菜单里是否直接包含分组项、以及分组管理是否独立成页。这三项在版本之间也可能变化，因此不建议把某一端的操作习惯直接套用到另一端。共同风险只有一个：删除操作的确认成本低。移动端屏幕小、误触概率高，删除分组前建议先确认组内是否还有需要保留的标的。

六、分组数据存在哪里：本地缓存与账号同步

这是全文最需要说清楚的一节，因为它直接决定了“数据留不留得住”。粗略地讲，自选股与分组结构有两条存放路径：一条是设备本地的缓存，一条是登录账号后的云端同步。未登录状态下，分组结构主要依赖本地存储；登录后，分组通常随账号同步到服务端，从而在其他设备上可见。两条路径的区别，在换机、重装这类场景里会被放大成“重建半天”还是“刷新一下”的差距。

经验性观察：卸载重装、清理应用数据、更换设备而未登录同一账号，都有可能导致分组结构与成员丢失。这个结论是定性的，不做精确量化，但可以用一个可复现的验证步骤来确认自己的账号是否处于同步状态：在 A 设备新建一个空分组并命名，等待一段时间后在 B 设备登录同一账号并下拉刷新自选页，观察该分组是否出现。出现即说明同步链路可用；未出现则需检查登录状态与网络环境。

从可审计的角度看，同步状态本身就是一个需要被记录的事实。建议在每次大规模调整分组前后各截一张图，文件名带上日期。这个动作成本极低，但在设备丢失或账号异常时，能把“重建成本”从半天压缩到十几分钟；更重要的是，它把“我记得当时分过组”变成了“我能证明当时分了什么组”。

七、迁移步骤：换机、重装与多端并行

迁移的核心不是“能不能同步”，而是“同步之后如何确认没有遗漏”。下面这套流程适用于换手机、重装客户端、以及在桌面端与移动端之间来回切换的场景。

1. 迁移前归档：在旧设备逐组截图，记录分组名称与成员数量。成员数量比成员名单更容易核对，也更容易发现遗漏。
2. 确认账号一致：在新设备登录时，核对登录方式与旧设备完全相同。手机号、第三方授权等不同登录方式可能对应不同账号，这一点最容易被忽略。
3. 主动触发刷新：登录后进入自选页，手动下拉刷新或切换一次页面，等待同步完成。
4. 逐组核对数量：以第一步记录的数量为基准，逐组比对。数量一致即视为通过，不必逐只核对名称。
5. 补录差异部分：对数量不一致的分组，优先检查是否有标的被放进了默认分组或“全部”视图。
6. 迁移后再归档：完成补录后再次截图，形成迁移前后的对照，便于日后排查。

多端并行时的取舍：如果习惯在桌面端做深度整理、在移动端只看不改，那么建议把“整理”这个动作固定在一个端上完成。两端同时改动的风险在于顺序不确定——可能出现以最后一次写入为准的情况，也可能出现重复分组。规避方法很简单：改动前先确认另一端已刷新到最新状态。把这条规则写进自己的操作习惯，比事后排查冲突要省力得多。

八、兼容性对照表

下表按平台罗列分组相关能力的大致支持情况。表中“视版本而定”的意思是：该能力在部分版本中存在，在另一些版本中入口位置或交互方式不同，需以实际客户端为准，不作功能承诺。

能力	桌面端	Android	iOS
新建分组	支持	支持	支持
重命名分组	支持	视版本而定	视版本而定
拖动排序	视版本而定	视版本而定	视版本而定
批量移动到分组	较易实现	操作成本较高	操作成本较高
跨端同步	需登录同一账号，同步时机与实时性以实际表现为准
导出为文件	客户端未提供显式入口，建议用截图归档替代

从表中可以读出一个结论：分组的“创建”能力在各端都比较稳定，“整理”能力则明显偏向桌面端。如果你的分组结构比较复杂，比如超过十个分组且需要频繁调整顺序，把主要整理工作放在桌面端完成，再用移动端消费，是成本最低的分工方式。反过来，如果整理工作主要发生在手机上，那就不必设计过于精细的分组体系，够用即可。

九、风险控制与可审计实践

分组功能本身没有合规风险，真正的风险来自“记录失真”——分组名含糊、成员随意堆叠、调整无痕迹，导致日后无法还原判断过程。控制手段不需要复杂工具，几条命名与操作规则就够了。

9.1 命名规范：让分组自己解释自己

推荐使用“前缀 + 用途”的两段式命名，例如以 S 开头表示短线、M 表示中线、R 表示复盘。前缀的好处是排序稳定，不随汉字拼音变化；用途部分则回答“这一组是干什么的”。不建议用具体日期作为分组名，因为这类分组会随时间不断膨胀，半年后标签栏会被大量历史分组占满，切换效率随之下降。

什么时候不该追求命名规范：如果分组只是临时用一两个小时，为了命名而命名反而增加负担。此时用一个显而易见的临时名称、用完即删，比维护一套体系更实际。规范的适用边界是“跨天存在”的分组，当日用完即弃的分组不必遵守。

9.2 误删与同步冲突的处置

删除分组时的行为在不同版本上可能不同：有的只删除分组容器，组内标的回到默认分组；有的会连同成员一起移除。经验性观察：这一行为没有统一的界面提示，误判的代价不小。可复现的验证方法是：新建一个空的测试分组，放入一只不重要的标的，删除该分组后检查这只标的是否仍在自选列表中。整个过程不到一分钟，却能提前摸清行为边界。

同步冲突的处理原则是“先定锚、再改动”。改动前先在某一端刷新到最新状态并截图，作为锚点；发现异常时以锚点为准逐组比对，而不是凭印象补录。这个习惯在分组数量较多时尤其有价值，因为它把“我记不清了”变成了“我有图可查”。

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

下面按“现象—可能原因—验证方法—处置”的顺序列出几类常见问题。所有条目都给出可复现的验证动作，避免仅凭猜测下结论。

现象	可能原因	验证方法	处置
找不到分组入口	版本布局差异，或窗口过窄导致标签栏折叠	拉宽窗口后重新查看；逐一展开“管理”“编辑”类按钮	改用分组管理面板，或升级到当前最新版本
新设备上看不到旧分组	登录账号不一致，或同步尚未触发	比对登录方式；在自选页手动刷新后再次查看	切换为同一登录方式，重新触发刷新
分组出现重复	多端同时改动，写入顺序不确定	查看两端的分组列表并截图对照	保留内容完整的一组，另一组手工合并后删除
分组内标的数量对不上	执行“移动”语义后原组不再保留该标的	把某只股票从 A 组移动到 B 组，回查 A 组	需要多点留存时，改用“添加”而非“移动”

排查时最容易走偏的一步，是把所有异常都归因于“同步坏了”。实际上，入口位置变化、语义差异、账号不一致，这三类原因出现的频率更高。建议按“先看界面、再看账号、最后看网络”的顺序排查，能省下大量无谓的等待——多数情况下，问题在第一步就能被定位。

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

分组是一件“够用就好”的工具，过度设计反而增加维护成本。下面两组条件可以帮助你快速判断该不该投入时间。

值得做的情形：自选股数量稳定在三十只以上；不同标的的跟踪周期差异明显（有的看日线、有的看季报）；需要在复盘时快速还原“当时在看什么”；使用桌面端为主，整理成本较低。

不必要的情形：自选股长期在十只以内，一屏能看完；跟踪周期高度一致，分组之间没有实质差别；以移动端为主且很少做批量整理；分组只是情绪化地“分个类”，从不回看。经验性观察：当分组数量超过实际使用场景数量时，切换带来的认知负担会抵消它节省的时间，此时减少分组比增加分组更有效。

十二、最佳实践检查表

把前面各节的结论压缩成一张可执行的清单，每次调整分组结构前过一遍，能避开绝大多数返工。

• 确认已登录账号，且与旧设备使用同一种登录方式。
• 常用分组控制在五到七个，临时分组用完即删。
• 分组名采用“前缀 + 用途”结构，不使用纯日期命名。
• 批量整理集中在桌面端完成，移动端只做查看与微调。
• 执行“移动”前确认语义，需要多头保留时改用“添加”。
• 调整前后各截一张图，文件名带日期，作为变更留痕。
• 删除分组前，先用测试分组验证它对成员的影响。
• 定期核对分组数量与成员数量，与归档截图比对。

这张清单的重点不在条目多，而在于它把“设置”变成了“流程”。分组的价值实现于长期使用，而不是配置完成的那一刻。把它当成一次性的界面调优，收益会很快消失；把它当成一套可复核的记录习惯，收益才会随使用时长累积。

十三、常见问题（FAQ）

结语：把分组当成一份可复核的记录

回到最初的问题，同花顺自选股分组的设置本身并不复杂：桌面端在自选页的分组标签区新建、右键归组、点标签切换；移动端在自选页顶部的分组条完成同样的动作。真正决定这套功能是否好用的，是三个习惯——命名让分组自解释、整理集中在单一端完成、调整前后留一份截图。它们共同把“界面设置”变成了“可复核的记录”。

下一步建议按这个顺序推进：先花十分钟把现有分组按“前缀 + 用途”重命名，删掉两周以上没有打开过的临时组；然后完整走一遍迁移核对流程，确认账号同步确实生效；最后把截图归档加入你的周末复盘动作。做完这三步，分组才算真正开始为你的看盘效率服务。至于后续版本是否会调整入口位置、是否会改变同步时机，属于无法预判的部分；本文给出的定位思路与核对流程不依赖具体布局，入口变化时仍可复用。