【日期选择】Lazada 平台日期选择

一、问题场景

在 Lazada Seller Center 平台(sellercenter.lazada.sg)，需要根据不同的日期范围查询对应的数据。

二、遇到的问题

一开始是直接使用智能日期选择器，但选择器无法正确选择。

经过观察发现，Lazada 平台的日期选择器存在一个比较特殊的问题：

一开始点击“自定义日期”时，可以正常显示当前月份（例如 9 月）的日期。但是一旦切换月份后，日期选择器中的月份显示就会出现歧义。

例如当前月份是 9 月，切换到 8 月后，日期选择区域主要显示 8 月的日期，但在 8 月日期区域的最后几天，又会显示部分 9 月的日期。

也就是说：

需要超过 9 月第一排日期的显示范围后，系统才会真正显示 9 月的日期，否则 9 月的部分日期会显示在 8 月的日期区域中。

对于人工操作来说，这个问题影响不大，因为人可以根据日期位置、上下月份等信息判断具体是哪一天。

三、解决方案

通过观察发现，进入取数页面后，URL 中本身就包含了日期范围参数。不管是哪个页面，只要是带有日期选择的，URL 中都会包含对应的日期范围信息。

例如：

https://sellercenter.lazada.com.ph/ba/dashboard?spm=xxx&dateRange=2026-08-06%7C2026-08-07&dateType=range

其中：

dateRange=2026-08-06%7C2026-08-07

就是页面当前选择的日期范围。

而不同页面支持的 dateType 可能不同，具体需要根据页面实际使用的日期类型来确定。例如：

day
week
month
range

%7C 是什么？

%7C

实际上是 URL 编码，对应：

|

所以实际含义就是：

dateRange=2026-08-06|2026-08-07

也就是说：

2026-08-06

是开始日期，

2026-08-07

是结束日期。

那么问题就简单了

既然页面 URL 已经记录了日期范围，那么就不需要再让 RPA 去操作那个容易产生月份歧义的日期控件。

例如原来的 URL：

https://sellercenter.lazada.com.ph/ba/dashboard?spm=xxx&dateRange=2026-08-06%7C2026-08-07&dateType=range

如果需要查询：

2026-08-10 ~ 2026-08-11

那么只需要把：

dateRange=2026-08-06%7C2026-08-07

修改成：

dateRange=2026-08-10%7C2026-08-11

最终访问新的 URL 即可。

这样就绕过了原来的日期选择控件。

四、最终效果

修改 URL 后，Lazada 会根据 URL 中的 dateRange 和dateType 加载对应日期的数据。

整个 RPA 流程也可以从原来的：

打开页面
↓
点击日期控件
↓
判断当前月份
↓
寻找目标月份
↓
点击日期
↓
处理跨月日期
↓
确认日期
↓
获取数据

简化成：

访问目标URL
↓
获取对应日期的数据

这样不仅日期选择稳定了，RPA的操作步骤也减少了。

五、进一步优化

实际使用过程中，Lazada 通常需要获取多个站点的数据。

如果针对每个站点都直接硬编码完整 URL，例如：

https://sellercenter.lazada.com.ph/ba/dashboard?...
https://sellercenter.lazada.sg/ba/dashboard?...
https://sellercenter.lazada.co.th/ba/dashboard?...

后续维护起来会比较麻烦。

因此，更推荐：

获取当前页面 URL，只修改 dateRange 和 dateType 参数，其他参数全部保留。

获取当前 URL
↓
解析 URL 参数
↓
只修改 dateRange
↓
保留其他参数
↓
重新生成 URL

Python 中可以使用 urllib.parse 来处理：

from urllib.parse import urlparse, parse_qs, urlencode, urlunparse


def change_date_params(url, date_type, start_date, end_date):
    """
    修改 URL 中的日期参数。

    :param url: 原始 URL
    :param date_type: 日期类型
    :param start_date: 开始日期，例如 "2026-08-01"
    :param end_date: 结束日期，例如 "2026-08-31"
    :return: 修改后的 URL
    """

    parsed = urlparse(url)
    params = parse_qs(parsed.query)

    params["dateType"] = [date_type]
    params["dateRange"] = [f"{start_date}|{end_date}"]

    new_query = urlencode(params, doseq=True)

    return urlunparse((
        parsed.scheme,
        parsed.netloc,
        parsed.path,
        parsed.params,
        new_query,
        parsed.fragment
    ))

例如：

url = "https://sellercenter.lazada.com.ph/ba/dashboard?spm=xxx&dateRange=2026-08-06%7C2026-08-07&dateType=range"

new_url = change_date_range(
    url,
    "range",
    "2026-08-10",
    "2026-08-11"
)

print(new_url)

这样做的好处是：

不需要关心 URL 中除了日期参数之外还有哪些参数，只修改真正需要修改的 dateRange 和 dateType，其他参数全部保留。

对于多个 Lazada 站点、不同功能页面，也不需要单独维护一套固定 URL，只需要获取当前页面 URL，再根据当前页面实际支持的日期类型传入参数即可。

六、踩坑提醒

这次问题给我的一个比较大的启发是：

做 RPA 时，不一定所有问题都要通过“模拟人工点击”来解决。

当遇到一些比较复杂的网页控件时，可以尝试换一个角度：

页面上的操作，最终是不是会反映到 URL、接口参数或者页面状态中？

如果能找到对应的参数，就可以考虑直接修改参数，而不是强行让 RPA 模拟人工操作。

尤其是日期、分页、筛选条件、排序等功能，有些网站会直接把这些状态保存在 URL 中。

这种情况下：

操作页面控件

未必是最稳定的方案。

有时候：

修改 URL 参数

反而更加简单、稳定。

当然，实际使用时还是需要注意：

1. 不同 Lazada 页面支持的 dateType 可能不同。

2. 不能默认所有页面都支持 range。

3. 修改 URL 前，需要确认当前页面实际使用的 dateType。

4. 修改后需要验证页面是否能够正确加载对应日期的数据。

5. 最好测试跨月、跨年等日期场景，确保 URL 参数确实能够控制页面状态。

最终总结：

当 RPA 遇到日期选择器月份判断困难时，不妨先观察页面 URL。
如果日期已经被记录在 URL 参数中，可以考虑直接修改日期参数，从而绕过复杂的日期控件。